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PREFACL 


This  report  under  Contract  DAHC  15-73-C-0077  describes  a program 
aimed  at  the  demonstration,  test  and  evaluation  of  the  educational  and 
economic  effectiveness  of  tho  PLATO  IV  computer-based  education  as  imple- 
mented in  several  geographically  dispersed  military  training  sites.  It 
also  describes  a program  aimed  at  increasing  the  cost  effectiveness  of  the 
PLATO  system,  both  in  its  deployment  in  the  ARPA  community  and  in  its  con- 
tinuing development  as  a national  resource  for  education. 
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PART  I 

SITE  5UPP0PT  PROGRAM  FOR 
SERVICE  TEST  OF  PLATO  IV 


INTRODUCTION  TO  THE  SITE  SUPPORT  PROGRAM 


This  report  describes  a program  aimed  at  the  demonstra- 
tion, test,  and  evaluation  of  the  educational  and  economic  effective- 
ness of  the  PLATO  IV  computer-based  education  system  as  implemented  and 
tested  in  several  geographically  dispersed  military  training  sites. 

Familiarity  v.±ch  the  two  preceding  repiorts  of  this  project 
will  facilitate  understanding  of  this  one.  These  will  be  referred  to 
as  The  First  Annual  Report"  and  "The  Second  Annual  Report."  The 
First  Annual  Report  nominally  covers  the  time  from  August  1,  1972,  to 
•January  1,  1974;  the  Second  Annual  Report  covers  January  1,  1974  to 
December  ?1,  1974. 

Note;  Due  to  shifts  in  the  reporting  schedule,  some  of  the 
data  presented  and  the  activities  described  in  this  report  fall  into 
the  period  beginning  September  1,  1974.  All  data  not  otherwise  labeled 
is  assumed  to  be  for  the  period  beginning  January  1,  1975  to  June  30, 


1.1  MTC  ACTIVITIES 


The  MTC  group  was  established  in  1972  primarily  to  pro- 
vide the  ARPA/PLATO  sites  with  TUTOR  training  and  programming  consul- 
tation. In  response  to  the  varied  needs  of  the  several  sites,  how- 
ever, MTC  began  to  undertake  and  now  carries  out  a wide  variety  of 
additional  tasks.  Because  of  the  generally  high  level  of  programming 
competence  at  the  sites,  the  most  important  services  MTC  provides  for 
the  sites  falls  under  the  general  category  of  instructional  design. 

Under  this  category  fall  the  activities  of  assisting  with  lesson  design 
and  curriculum  development,  providing  lesson  reviews  and  revisions, 
and  consulting  on  lesson  validation.  Also,  because  MTC  has  been  able 
to  watch  the  inception  and  growth  of  several  remote  PLATO  sites,  it  has 
been  able  to  offer  advice  on  project  planning,  staffing,  and  manage- 
ment. Finally,  MTC  serves  as  a general  liaison  between  the  15  remote 
sites  and  CERL. 

Most  of  these  services  are  adequately  provided  by  means  of 
inter-terminal  and  telephone  communications.  However,  more  extended 
contact  are  sometimes  needed,  and  for  those  cases,  MTC  staff  members 
spent  approximately  71  man-days  during  the  last  ten  months  on  consulting 
visits  to  the  sites  while  hosting  site  visitors  for  about  40  man-days. 

1.1.1  TRAINING  AND  CONSULTATION 

The  series  of  reference  lessons  on  TUTOR  created  by  MTC 
several  years  ago  for  novice  programmers  is  still  being  used  at  the 
rate  of  approximately  75  times  per  week  even  though  it  has  not  been  ad- 
vertised for  2 years  and  is  not  mentioned  in  any  official  literature. 
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During  this  reporting  period,  four  authors  from  Sheppard 
Air  Force  Base  and  six  from  Maxwell  Air  Force  Base  (See  sections  1.27 
and  1.25.)  were  given  MTC ' s courses  on  the  fundamentals  of  the  TUTOR  lan- 
guage and  on  instructional  design.  Fach  of  these  courses  was  revised 
before  presentation  with  the  major  modifications  being  the  inclusion  of 
parts  of  a yet  unpublished  book  on  lesson  review  and  the  expansion  of 
the  lesson  development  section  of  the  instructional  design  course. 

1.1.2  SUPPORT  PROGRAMMING 

At  this  time,  most  sites  have  reached  a level  of  competency 
in  the  use  of  the  TUTOR  language  that  matches  their  current  needs. 

Thus,  they  require  a minimal  amount  of  help  with  day— to— day  coding  prob- 
lems. The  assistance  once  provided  by  MTC  in  this  area  now  centers  mainly 
on  the  more  advanced  facets  of  TUTOR.  In  particualr,  since  several 
of  the  sites  are  in  the  final  stages  of  their  projects,  they  have  needed 
help  with  the  collection  of  data  either  through  the  packages  already 
available  on  the  system  or  with  collection  routines  fashioned  for  their 
special  needs. 

At  several  sites  we  have  promoted  the  use  of  and  provided 
help  with  sy stem- furnished  data  crunching  routines  such  as  "area,"  "qarea," 
course,  etc.  We  also  worked  to  devise  special  data  compacting,  storage, 
and  retrieval  routines  for  experimental  data  being  gathered  by  HumRRO 
authors . 

Another  area  of  significant  work  in  support  programming 
has  been  the  development  (in  progress)  of  routines  which  will  circumvent 
the  problems  caused  by  telephone  line  errors  at  remote  sites  which  affect 
plasma  display  and  touch  routines. 
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Also,  to  date,  five  diagnostic  mathematics  tests  employing 
a complex  branching  algorithm  have  been  designed  and  programmed.  Each 
analyzes  a student’s  strengths  and  weaknesses  in  some  fundamental  area 
of  mathematics.  The  topics  of  the  presently  existing  test  are: 

1.  Addition,  subtraction,  multiplication,  and  division  of 
positive  integers 

2.  Addition,  subtraction,  multiclication,  and  division  of 
positive  rational  numbers  with  a section  testing  comprehension  of  basic 
terminology  of  rational  numbers,  e.g.,  numerator,  denominator,  lowest 
common  denominator,  reduced,  etc. 

3.  Conversion  of  rational  numbers  to  decimal  repre- 
sentation, and  addition,  subtraction,  multiplication,  and  division  of 
decimal  numbers 

4.  Multiplication  and  division  of  decimal  numbers  by 
integral  powers  of  ten 

5.  Addition,  subtraction,  multiplication,  and  division  of 
numbers  with  integral  exponents. 

1.1.3  LESSON  REVIEW 

A very  busy  reviewing  schedule  has  been  maintained  (particu- 
lar ily  with  the  Sheppard  project).  Details  are  given  in  section  1.2  — 
"Interactions  with  the  Sites."  In  addition,  a significant  portion  of  the 
last  eight  months  was  spent  readying  for  publication  a paper  antitied 
Lesson  Review.  Authored  by  MTC  staff  members,  it  describes  the  review 
procedures  developed  by  the  group  based  on  its  experiences  with  the 
ARPA  sites. 

The  150  page  book  details  topic  such  as: 

1.  The  rationale  and  importance  of  reviewing 
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2.  The  uses  of  a review 

3.  Various  reviewing  procedures  and  techniques 

It  includes  examples  of  the  different  types  of  lesson  reviews  as  well 
ss  practice  exercises  for  the  reader.  The  substance  and  approach  of 

~ ReV-1-'g  make  the  b°°k  ^“able  to  authors  and  reviewers,  but 
it  could  also  be  useful  for  project  directors  wishing  to  know  some  of 
the  pitfalls  of  lesson  development. 

1.1.4  LESSON  CO-DEVELOPMENT 

During  this  reporting  period,  "Sheppard  East,"  MTC's 
support  group  for  the  School  of  Health  Care  Sciences  at  Sheppard  AFB, 
undertook,  with  the  staff  at  Sheppard,  Joint  development  of  some  les- 
son materials.  In  this  endeavor,  the  major  effort  was  to  write  simu- 
lated patient  encounters  since  one  of  the  MTC  staff  already  had  ex- 
tensive experience  in  this  ana.  For  these  simulations,  Sheppard  East 
assisted  in  the  design  of  the  lesson  formats  and  coded  extensive  -help- 
sequences  and  data  collection  routines.  This  group  also  arranged  for 
students  associated  with  the  PLATO  medical  network  to  use  the  patient 

encounters  as  lesson  so  that  data  for  formative  evaluation  could  be 
gathered. 

In  other  efforts  to  co-develop  lessons,  Sheppard  East 
co-developed  a lesson  on  pulmonary  function  testing.  A Sheppard  author 
wrote  a hard  copy  "script"  and  members  of  Sheppard  East  used  this 
script  as  a basis  for  designing  the  lesson  as  it  was  to  be  presented 
on  PLATO.  Because  of  the  problems  inherent  in  dividing  the  complex 
task  of  lesson  development  in  this  way  and  in  separating  the  developers 
by  many  miles,  we  envision  continued  co-development  only  for  those  les- 
sons that  would  gain  special  benefit  by  being  developed  at  CERL. 
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1.1.5  COOPERATIVE  EFFORTS 

The  pattern  of  liaison  activities  established  during  the 
first  two  years  of  the  ARPA/PLATO  project  (cf.  section  2.6.2  of  the 
Second  Annual  Report)  has  been  maintained  in  this  reporting  period  at 
a somewhat  reduced  level  due  to  the  state  of  near  completion  of  several 
of  the  remote  sites.  These  activities  still  include  distribution  and 
naming  of  file  spaces,  acquisition  of  inventory  information,  terminal 
repair  verification,  and  borrowing  or  copying  microfiche. 

One  liaison  function  MTC  no  longer  performs  is  that  of  memory 
allocation  supervision  or  ECS  monitoring.  Before  January,  1975,  when 
an  additional  one  million  words  of  ECS  was  installed,  this  activity  was 
a necessity  tn  insure  that  there  would  be  sufficient  memory  available 
for  the  sites  to  carry  out  their  missions.  Since  January,  there  have 
been  no  shortages  of  ECS  nor  are  any  anticipated. 

At  the  same  time  that  the  additional  ECS  was  being  in- 
stalled, several  system-level  packages  that  greatly  increased  the  capa- 
bilities of  local  site  directors  were  introduced  for  general  use.  Since 
the  advantages  of  these  packages  could  best  be  used  by  grouping  terminals 
into  logical  sites  according  to  the  purposes  those  terminals  were  serving, 
the  ARPA  terminals  were  grouped  into  five  logical  sites.  Then  a site 
director  for  each  site  was  selected  and  trained  in  the  use  of  the  direc- 
tor's capabilities.  These  capabilities  include  being  able  to  restrict 
the  user's  terminal  access,  send  instantaneous  messages  to  users,  de- 
lete users  from  the  system,  etc. 

The  use  of  the  communication  features  on  PLATO  continues  to 
play  an  integral  role  in  the  day-to-day  functions  of  ARPA  authors.  From 
September,  1974  to  June  30,  1975,  a total  of  5,000  personal  notes  were 


received  by  ARI'A  authors  through  the  newly  instituted  system  mail 
feature.  With  the  advent  or  this  feature,  the  MTC  communications  program 
-itc-  was  retired.  Also,  a large,  but  unrecorded  number  of  "talk"  con- 
versations were  used  by  remote  ARPA  authors  to  maintain  contact  with 
other  users,  and  to  request  and  receive  MTC  and  CERL  services. 

In  the  future,  we  anticipate  that  the  liaison  activities 
will  reflect  the  fact  that  the  curriculum  development  sites  are  becoming 
involved  with  their  final  reports  and  evaluations.  In  the  case  of 
Aberdeen,  for  example,  MTC  compiled  terminal  maintenance  records 


1.2  INTERACTIONS  WITH  THE  SITES 

1.2.1  U.S.  ARMY  ORDNANCE  CENTER  AND  SCHOOL 
ABERDEEN  PROVING  GROUNDS 

The  final  phase  of  the  Aberdeen  project  has  required 
fewer  inputs  than  did  earlier  phases.  All  lesson  development  was  com- 
pleted by  late  1974;  hence  few  requests  in  the  areas  of  lesson  review 
and  revision  were  made.  The  main  MTC  efforts  were  directed  towards 
maintaining  and  modifying  the  data  crunchers  designed  for  Aberdeen's 
project.  In  addition,  a number  of  statistical  routines  and  procedures 
were  reviewed  or  suggested  by  the  PEER  group  personnel. 

Aberdeen  completed  all  of  their  student  runs  in  May  1975, 
and  the  staff  is  now  finishing  their  final  report.  They  will  soon  be- 
gin redistribution  of  their  terminals  to  other  sites. 

1.2.2  FORT  BELVOIR 

Fort  Belvoir's  terminals  came  on-line  during  May  1975.  They 
sent  two  staff  members  to  Aberdeen  for  a brief  familiarization  with  the 
system.  Two  MTC  staf  f members  visited  Fort  Belvoir  in  April  to  assist 
in  planning  for  the  use  of  the  terminals. 

1.2.3  CHANUTE  TECHNICAL  TRAINING  CENTER 
CHANUTE  AIR  FORCE  BASE 

In  January  1975,  the  courseware  that  Chanute's  PLATO 
project  had  been  directed  to  develop  (cf.  the  Second  Annual  Report, 
section  3.1.2)  was  substantially  completed  and  ready  for  student  vali- 
dation. This  validation  procedure  which  requires  that  27  of  30  students 
must  meet  pre-established  testing  criteria  has  continued  throughout 


this  reporting  period,  and  as  of  July  1975,  about  80%  of  the  lessons 
had  been  validated.  The  Instructional  Systems  design  scalf  at  Chanute 
anticipates  that  all  the  lessons  will  be  validated  by  October  1975,  and 
they  will  cease  to  take  evaluation  data  on  these  lessons  at  that  time. 

During  this  period  of  developing  lesson  material  for  the 
Special  Vehicle  Computer  Based  Training  System,  very  little  advice  on 
educational  matters  was  sought  from  the  MTC  group  since  the  ISD  team 
used  lesson  development  techniques  adapted  to  producing  efficient  mili- 
tary training  instruments.  MTC  did,  however,  serve  as  a technical  lia- 
ison between  the  PLATO  project  at  Chanute  and  CERL.  In  this  role,  for 
example,  MTC  raciiitated  the  production  of  102  microfiche.  MTC  urged 
the  manufacture  by  CERL  of  a microfiche  mounter  so  that  the  photo- 
graphic personnel  at  Chanute  could  not  only  develop  but  also  mount  their 
own  microfiche.  Two  mounters  were  delivered  to  Chanute  in  April  1975. 

The  presence  of  the  mounters  at  Chanute  and  the  fact  that  Chanute  de- 
velops their  own  microfiche  has  reduced  their  microfiche  production  time 
from  eight  or  more  days  to  as  little  as  two  days. 

In  February,  review  of  Chanute’ s PLATO  project  was  held  at 
the  request  of  ARPA.  At  ATC’s  request,  MTC  made  an  assessment  of  the 
courseware  being  developed  as  well  as  of  Chanute 's  evaluation  plans.  The 
courseware  assessment  was  made  on  the  basis  of  lesson  features  and  options 
rather  than  on  student  data  hecause  at  that  time  limited  student  data  was 
available.  Based  on  progress  reports  and  assessments  delivered  at  the 

meeting,  goals  and  directions  were  established  for  the  continuation 
phase  of  the  project. 

1.2.4  HUMAN  RESOURCES  RESEARCH  ORGANIZATION 
HumRRO 

A large  set  of  data  reduction  routines  were  written  by 
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MTC  and  CERL  for  HumRRO.  Specifications  for  these  data  collection  pro- 
grams (for  experiments  conducted  at  Fort  Belvoir)  were  the  topics  of 

discussion  during  a three  day  visit  to  CERL  by  three  of  the  HumRRO 
staff . 

1.2.5  AIR  UNIVERSITY 

MAXWELL  AIR  FORCE  BASE 

Maxwell  Air  Force  Base  came  on-line  in  June  with  four  ter- 
minals. The  MTC  group  conducted  a two-week  PLATO  training  program  on 
site.  The  first  week  consisted  of  training  in  the  TUTOR  language;  the 
second  was  devotee  to  introducing  sound  instructional  design  techniques 
to  the  authoring  staff  there.  Maxwell  plans  a comparison  of  TICCIT  and 
PLATO  for  teaching  career  development  courses. 

1.2.6  NAVAL  TRAINING  EQUIPMENT  CENTER 
ORLANDO 

The  Orlando  staff,  in  cooperation  with  personnel  from  the 
Institute  of  Social  Research,  published  a repot t on  their  pilot  study 
for  teaching  interpersonnel  skills.  Based  on  the  successes  and  failures 
found  in  this  initial  study,  Orlando,  in  February,  began  to  reorganize 
their  courseware.  They  are  structuring  their  lessons  in  a new  format 
which  will  subsume  most  of  their  previously  written  lessons  and  require 
the  creation  of  many  new  ones.  Support  to  Orlando  NTEC  included  datafile 

manipulation,  data  reduction  and  display,  lesson  reviews,  and  evaluation 
suggestions. 

1.2.7  SCHOOL  OF  HEALTH  CARE  SCIENCES 
SHEPPARD  AIR  FORCE  BASE 

Shpeast , that  part  of  the  MTC  group  that  is  concerned 
mainly  with  providing  support  for  the  Sheppard  Project,  has  been  working 
with  the  Sheppard  authors  on  new  types  of  reviewing  techniques  to  help 
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bring  authors  and  consultants  into  closer,  more  frequent  contact  and  thus 
hopefully  speed  quality  lesson  development  (see  sections  1.1.3  "Lesson 
Review"  and  section  1.1.4  "Lesson  Co-Development").  In-depth  reviews 
for  about  40  lessons  were  done  in  preparation  for  the  first  student  vun 
starting  on  July  2,  1975. 

The  math  diagnostic  test  materials  written  by  MTC  (see 
section  1.2  "Support  Programming"),  were  used  by  the  February  Physician 
Assistant  class  at  Sheppard.  See  section  1.1,4  for  a description  of 
the  lesson  co-development  carried  on  with  Sheppard. 

Throughout  the  year  MTC's  consulting  trips  to  Sheppard 
were  augmented  by  visits  from  individuals  and  small  groups  of  people 
from  Sheppard.  In  addition  to  dealing  with  specific  items  such  as 

: 

TUTOR  training,  advanced  TUTOR  consulting,  Varian  hardcopiar  mainten- 
ance, and  the  Chanute  Review,  the  visits  helped  maintain  an  exchange 
design  and  Sheppard's  upcoming  evaluation  plan. 


1.3 


SUMMARY  INFORMATION 


Note: : 


For  a detailed  explanation  of  the  following  tables,  see  section 
3.2  "Summary  Information"  in  the  Second  Annual  Report. 
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1.3.2 


TERMINAL  DELIVERY  AND  RJ.-ASSIGNMENT 


1/74  - 6/75 


15 


16 


1.3. 3.1 

PLATO  IV  - Terminal  Usage 
December  1,  1974  - March  31,  1975 

User  Terminal  3 Mean  Hours  per  Week  per  Terminal 

(March  1975}  December  January  February  March 


Prime 

Total 

Prime 

Total 

Prime 

Total 

Prime 

Total 

CERL 

64 

23.8 

36.1 

21.2 

32.2 

28.6 

45.4 

27.4 

39.6 

U of  I 

285 

22.4 

32.6 

14.6 

21.3 

28.3 

42.3 

25.9 

39.2 

111.  Univ. ' s 

76 

- 

- 

11.2 

15.3 

17.2 

24.1 

16.3 

21.6 

Other  Univ.'s 

61 

20.7 

32.6 

27.0 

43.7 

31.3 

51.8 

26.6 

44.6 

Comm.  Coll.'s 

117 

15.5 

15.9 

9.3 

10.8 

13.6 

14.9 

21.1 

22.1 

Schools 

88 

10.3 

10.4 

8.5 

10.1 

10.3 

11.3 

11.4 

12.0 

Government 

25 

15.4 

20.2 

14.8 

18.8 

20.4 

25.8 

21  .0 

25.6 

Military 

99 

12.8 

15.4 

13.1 

17.0 

13.9 

17.8 

14.7 

17.6 

Commercial 

12 

11.1 

12.7 

20.6 

27.2 

18.0 

24.5 

21.6 

28.9 

April  1, 

1975  - June  30, 

1975 

User 

Terminals 

Mean  Hours 

per  Week  per 

Terminal 

(June  1975) 

April 

Prime  Total 

May 

Prime  Total 

June 

Prime  Total 

CERL 

62 

26.6 

40.0 

24.3 

32.8 

27.9 

36.2 

U of  I 

285 

27.8 

42.5 

18.8 

28.0 

16.7 

22.5 

111.  Univ.'s 

73 

23.4 

31.2 

21.1 

25.8 

16.1 

19.3 

Other  Univ.'s 

69 

31.5 

53.6 

30.7 

49.3 

32.0 

46.5 

Comm.  Coll. ' s 

118 

22.5 

24.0 

17.7 

17.9 

9.0 

8.6 

Schools 

76 

12.7 

13.8 

11.1 

11.2 

3.6 

3.7 

Government 

26 

18.8 

22.4 

16.5 

18.7 

20.1 

22.0 

Military 

104 

15.8 

19.0 

13.4 

14.8 

17.5 

18.1 

Commercial 

10 

23.0 

31.2 

21.5 

26.4 

28.7 

35.0 

1.3. 3. 2 
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ARPA  Terminal  Usage 
December  1,  1974  - March  31,  1975 

User  Terminals  Mean  hours  per  Week  per  Terminal 

(March  1975)  December  January  February  March 

Prime  Total  Prime  Total  Prime  Total  Prime  Total 


ARFA-MAIN 

'1 
4 . 

0.0 

0.3 

1.2 

2.4 

22.7 

24.5 

6.2 

6.4 

ARI 

1 

8.6 

9.0 

21.4 

24.7 

32.7 

36.4 

38.9 

41.9 

ARPA-CERL 

2 

34.0 

40.5 

33.5 

44.0 

22,8 

30.8 

27.7 

34.1 

Aberdeen 

14 

14.8 

15.0 

11.5 

13.7 

11.5 

13.7 

12.0 

12.6 

Chanute 

23 

7.7 

8.1 

7.7 

9.3 

12.9 

14.2 

16.9 

18.8 

Monmouth 

2 

16.1 

16.4 

17.4 

19.8 

18.2 

23.1 

17.3 

22.6 

Humrro 

4 

23.5 

31.5 

26.8 

33.5 

26.9 

36.0 

22.6 

27.8 

Lowry 

3 

18.0 

19.9 

10.0 

12.4 

7.2 

10.8 

13.5 

19.2 

San  Diego 

12 

12.8 

14.5 

20.2 

24.8 

18.9 

26.1 

16.0 

20.7 

Sheppard 

21 

9.3 

9.8 

8.7 

10.3 

9.1 

10.4 

11.2 

12.3 

use 

8 

14.9 

27.6 

16.6 

28.3 

13.0 

15.8 

7.2 

7.7 

Stanford 

3 

17.0 

52.5 

13.7 

35.5 

9.1 

30.2 

10.0 

31.5 

Orlando 

4 

25.3 

25.1 

24.7 

28.2 

26.9 

33.0 

29.1 

34.2 

April  1,  1975  - June  30,  1975 


Terminals  Mean  Hours  per  Meek  per  Terminal 

(June  1975)  April  May  June 

Prime  Total  Prime  Total  Prime  Total 


ARPA-MAIN 

2 

3.5 

3.7 

10.4 

10.5 

10.7 

10.3 

ARI 

1 

36.0 

38.5 

22.9 

23.3 

36.8 

36.7 

ARPA-CERL 

2 

27.0 

35.4 

18.6 

20.9 

27.7 

29.6 

Aberdeen 

14 

16.3 

17.2 

12.3 

12.4 

16.6 

16.3 

Chanute 

23 

19.4 

20.5 

16.1 

16.2 

20.7 

20.2 

Monmouth 

2 

31.8 

48.0 

30.7 

42.8 

18.8 

19.3 

Humrro 

4 

21.8 

24.8 

12.2 

13.8 

10.4 

12.1 

Lowry 

3 

15.6 

19.1 

16.2 

20.8 

22.0 

22.3 

San  Diego 

12 

16.6 

23.5 

15.8 

18.8 

19.0 

20.4 

Sheppard 

21 

11.2 

12.2 

9.6 

10.2 

13.2 

13.9 

use 

8 

6.7 

7.6 

6.1 

6.5 

4.3 

4.6 

Stanford 

- 

14.0 

43.1 

6.7 

16.1 

- 

- 

Orlando 

4 

31.9 

36.6 

22.5 

24.8 

26.9 

29.8 

Belvoir 

4 

0.0 

0.0 

11.7 

12.1 

31.8 

33.0 

Maxwell 

4 

- 

- 

- 

- 

20.6 

22.6 

i 
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INTRODUCTION  TO  THE  TECHNICAL  PROGRAM 


The  technical  program  at  CERL  has  for  over  a decade  been  guided  by 
considerations  of  both  performance  and  cost  in  the  delivery  of  high  quality 
education  through  the  interactive  use  of  computers.  This  work  has  led  to 
a new  display  device.,  the  Plasma  Display  Panel,  a new  interactive  graphics 
oriented  language,  TUTOR,  and  a new  architecture  for  information  processing. 
What  is  perhaps  most  important  is  that  these  and  other  developments  fit 
together  in  a highly  effective  system  which  is  greater  than  the  sum  of  its 
parts.  Part  II  of  this  ARPA  report  describes  the  status  of  a program  that 
with  ARPA  support  is  maintaining  the  momentum  of  technical  development  at 


CERL. 
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2.  AUXILLIARY  MASS  STORAGE 

The  AMS  memory  system  was  specifically  designed  to  satisfy  the 
stringent  performance  requirements  of  the  PLATO  computer  network  and  to 
provide  a swapping  memory  very  low  in  cost.  This  memory  system  consists 
basically  of  standard  semiconductor  serial  shift-register  devices,  con- 
figured to  allow  a fairly  sophisticated  controller  to  maniuplate  them 
according  to  commands  issued  by  the  CPU.  The  shift-registers  provide  an 
average  access  time  of  400  usees  and  a transfer  rate  of  600  megabits  per 
second,  achieved  through  parallelism.  The  use  of  eight  independent  sub- 
controllers causes  the  effective  access  time  to  approach  50  usees. 

There  are  two  fundamental  elements  in  the  AMS  memory:  the 

actual  memory  section  and  the  memory  controller. 

2.1  THE  AMS  MEMORY  STORAGE 

Figure  2.1  illustrates  the  organization  of  the  AMS  storage  elements. 
The  basic  element  utilized  is  a 1024  x 1 serial  shift-register  chosen  to 
operate  at  1.25  MHz.  Groups  of  eight  of  these  devices  have  been  arranged 
in  such  a fashion  that  a group  appears  as  if  it  were  a single  8192  x 1 
register  operating  at  a maximum  rate  of  10  MHc.  Furthermore,  64  groups  have 
been  paralleled  to  form  a file  unit  which  represents  the  basic  memory 
module.  The  basic  module,  called  a file,  is  an  8192  x 64  serial  register 
capable  of  reading  or  writing  10  t-illion  64-bit  words  per  second.  At 
these  rates,  and  since  the  file  is  serial,  the  average  access  time  to  an 


!L  limwww-.-.-'.  ■■(  ■-■  ui*iwi.j!,,.i!u1.i.  ,.ji,  j 
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1024x1  SHIFT- REGISTER 

< — . 

( I DEVICE  ) 
4>  - 1.25  MHZ 


x 8 


8192x1  SHIFT-REGISTER 

( 8 DEVICES  ) 
= 10.0  MHZ 


• x 64 


8 K woRns 

8192  x 64  SHIFT-REGISTER 

(512  DEVICES) 
( I FILE  ) 

<f>  - 10.0  MHZ 


65K  WORDS 


262K  WORDS 


4 M WORDS 


• x 8 


8 x 8192  x 64 


• x 


4x8x8192x64 


• x 16 


IS  x 4 x 8 x 8192  x 16 


(4096  DEVICES) 

(8  FILES  ) 

(I  QUADRANT) 

<f>  - 10.0 MHZ 

(16,384  DEVICES) 
(32  FILES) 

(4  QUADRANTS) 

( I BANK ) 

<f>  = 10.0  MHZ 

(262,144  DEVICES) 
(512  FILES) 

( 16  BANKS) 

- 10.0 MHZ 


AMS  MEMORY  ORGANIZATION 


Figure  2.1 
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individual  storage  location  varies  from  0 to  819.2  usees.  The  average 
access  time  is  therefore  419.6  gsecs. 

Any  number  of  files  can  be  installed  to  assemble  a complete 
memory:  groups  of  eight  were  chosen  as  the  minimum  size.  This  grouping 

is  called  a quadrant.  For  convenience  of  power  supply  and  chassis  wiring, 
groups  of  four  quadrants  are  arranged  as  banks . Banks  can  be  added  until 
the  total  memory  size  desired  is  achieved.  The  AMS  system  was  designed 
for  a maximum  of  16  banks. 

A file  is  8192  words,  a quadrant  is  65k  words,  a bank  is  262k 
words,  and  a fully  completed  AMS  system  would  be  four  megawords.  A word 
is  64  bits. 

2.2  THE  AMS  MEMORY  CONTROLLER 

The  heart  of  the  AMS  controller  is  an  array  of  eight  independent 
controllers.  These  units  are  called  subcontrollers  and  have  the  task  of 
manipulating  individual  files  for  the  purpose  of  data  transfer  into  and 
out  of  the  AMS  memory.  In  addition  to  the  subcontrollers,  there  are  several 
other  units  including  an  idle  controller  which  maintains  control  over  those 
files  not  under  the  control  of  a subcontroller,  and  a data  channel  through 
which  all  data  and  transfer  parameters  are  communicated. 

In  the  PLATO  system,  the  AMS  memory  is  connected  to  one  of  the 
ports  of  a high-speed  random  access  swapping  memory,  and  that  memory  in  turn 
is  connected  to  a high-speed  port  of  the  CPU's  central  memory.  The  high- 
speed random  access  memory  utilized  is  a product  of  Control  Data  Corporation 
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and  is  called  Extended  Core  Storage  (ECS).  This  memory  is  characterized  by 
a 3.2  Msecs  access  time,  600  megabit  transfer  rate  and  four  access  ports. 
Since  the  CPU  is  the  origin  of  all  of  the  AMS  control  parameters  and  is  the 
unit  that  interprets  the  status  information  provided  by  the  AMS  controller, 
a 128-word  buffer  communication  area  is  established  in  the  random  access 
swapping  memory  accessible  by  both  the  CPU  and  AMS.  The  CPU  plants  transfer 
parameters  called  job0  in  the  communication  area.  Groups  of  eight  of  these 
jobs  are  combined  and  called  batches . A job  contains  the  exact  parameters 
for  one  transfer  (file  number,  starting  address  within  a file,  starting 
transfer  address  in  the  random  access  memory  and  transfer  length).  A 
batch  containing  up  to  eight  jobs  is  intended  to  contain  a list  of  all  the 
jobs  that  would  be  required  by  the  CPU  to  service  a request  by  an  individual 
user:  program  files,  datafiles  and  status  information.  The  AMS  controller 

treats  the  group  of  transfers  within  a batch  as  a unit  and  supplies  the  CPU 
with  status  information  relative  to  the  entire  batch  as  well  as  relating 
to  the  individual  transfers.  In  this  manner,  the  CPU  is  relieved  of  the 
burden  of  figuring  out  whether  all  of  the  files  needed  for  a particular  user 
have  been  transferred  or  not. 

Presented  here  is  a description  of  the  sequence  executed  by  the  AMS 
controller  in  tiie  course  of  responding  to  a set  of  batches  posted  by  the  CPU. 

At  the  beginning  of  a CPU  execution  timeslice,  the  CPU  takes  the 
assemblage  of  keys  that  have  been  inputted  from  various  terminals  and  deter- 
mines what  files  of  data  will  be  required  for  each  key  to  be  processed.  The 
CPU  then  posts  the  proper  transfer  information  in  the  form  of  one  batch  for 
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each  user,  even  if  partial  batches  are  the  result.  In  the  meantime,  the 
AMS  controller  has  been  interrogating  the  communication  area.  As  soon  as 
the  CPU  has  posted  the  first  batch,  the  AMS  controller  begins  to  execute 
that  batch.  The  AMS  controller  samples  the  CPU-AMS  communication  area  only 
once  each  30  Msecs  in  order  to  avoid  jamming  the  ECS  data  channel  with  un- 
necessary transfers. 

Once  the  AMS  controller  has  recognized  that  a batch  has  been 
posted  by  the  CPU,  it  proceeds  to  assign  those  jobs  that  are  contained  in 
that  batch  to  the  eight  subcontrollers.  If  a batch  is  partially  filled, 

NOP  (no-operation)  jobs  are  assigned  to  the  unused  subcontrollers.  As  soon 
as  all  of  the  jobs  associated  with  a batch  have  been  assigned,  the  AMS  con- 
troller begins  to  interrogate  the  next  location  of  the  communication  area 
for  the  next  batch.  As  a batch  is  posted  in  this  location,  and  as  individual 
subcontrollers  become  completed  (those  with  NOP's  become  completed  immediately), 
parts  of  the  next  batch  are  assigned  to  the  idle  subcontrollers.  In  the  mean- 
time, the  AMS  controller  posts  status  information  in  the  control  area  where 
the  first  batch  was  picked  up,  overwriting  the  original  batch  parameters.  In 
this  fashion,  the  AMS  controller  attempts  to  keep  as  many  of  the  subcontrollers 
active  as  possible.  As  those  subcontrollers  that  were  issued  valid  jobs  be- 
come ready  for  transfer,  they  request  access  to  the  data  channel.  When 
granted  that  channel,  they  transfer  their  assigned  data.  After  transferring 
their  data,  the  subcontrollers  return  the  files  to  their  original  position 
and  detach  themselves.  At  this  point,  they  are  ready  to  accept  another  job. 

Any  unassigned  jobs  in  the  second  batch  are  assigned  to  the  subcontrollers. 
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At  the  point  that  all  of  the  jobs  in  the  original  batch  have  been  completed, 
the  AMS  controller  writes  status  information  to  the  control  area  one  last 
time,  indicating  that  the  entire  batch  was  completed,  and  proceeds  to  pick 
up  any  remaining  jobs  in  the  second  batch.  When  all  of  the  jobs  in  the 
second  batch  have  been  accepted  by  an  AMS  subcontroller,  the  AMS  controller 
proceeds  to  the  next  batch.  This  sequence  of  processing  one  batch  at  <1 
time  and  starting  the  next  batch  in  those  subcontrollers  that  are  idle  con- 
tinues until  all  of  the  batches  that  the  CPU  has  posted  have  been  processed. 
Chapter  5 discusses  in  detail  the  resultant  access  and  transfer  characteristics. 


2.3  SYSTEM  PERFORMANCE 

The  performance  of  the  AMS  memory  system  will  be  described  in  two 
sections:  1)  Controller  performance  and  2)  Memory  performance. 

2.3.1  CONTROLLER  PERFORMANCE 

The  PLATO  system  is  heavily  dependent  on  the  availability  of  a 
very  high-speed  mass  memory  and  presently  uses  two  million  words  of  Extended 
Core  Storage  (ECS).  In  this  memory  are  stored  many  types  of  data  necessary 
for  the  proper  operation  of  the  system.  The  position  of  an  AMS-type  memory 
as  a partial  supplement  to  the  large  ECS  bank  and  as  a further  extension  of 
this  memory  to  the  much  larger  numbers  of  words  necessary  to  service  thou- 
sands of  users  depends  on  its  ability  to  provide  a service  level  comparable 
to  that  of  the  present  ECS  system.  The  tasks  that  will  be  assigned  to  this 
new  memory  will  be  similar  to  but  increased  over  those  presently  assigned 
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to  the  ECS  memory.  The  AMS  controller,  whose  structure  determines  the  AMS 
system  performance,  was  designed  with  the  particular  characteristics  of  the 
PLATO  system  in  mind.  The  corresponding  performance  levels  of  the  controller 
were  determined  by  modeling  the  task  profile  of  the  PLATO  system  and  testing 
this  model  in  side-by-side  operation  of  PLATO  and  a parasitic  AMS  driver. 

The  model  for  the  AMS  controller  operation  takes  into  account  the 
following  parameters: 

1.  Transfer  length. 

2.  Search  length. 

3.  Return  length. 

4.  ECS  channel  access  queuing  and  CPU-AMS  access  conflicts. 

The  AMS  hardware  elements  involved  are: 

1.  The  actual  data  file. 

2.  The  eight  access  subcontrollers. 

3.  The  single  600  megabit  per  second  ECS  data  channel. 

4.  The  idle  file  controller. 

Definitions : 

Transfer  Length.  The  CPU  assigns  a transfer  length  to  an  AMS 
transfer  job  by  specifying  between  1 and  1024  records  to  be  transferred  (a 
record  is  eight  words).  The  data  length  will  be  transferred  to  or  from  ECS 
sequentially  from  the  starting  address,  which  is  also  specified  by  the  CPU. 

This  variable  is  indicated  as  TL  (Transfer  Length)  and  has  an  average  value  TL, 

Search  Length.  The  CPU  assigns  a starting  address  (from  0 to  1023 
records)  where  the  AMS  subcontroller  is  to  start  transferring  with  ECS,  and 
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the  subcontroller  must  rotate  its  specific  file  (always  in  the  forward 
direction)  from  its  instantaneous  position  to  this  starting  position.  The 
Search  Length  is  the  number  of  record  locations  that  the  subcontroller  is 
required  to  rotate  its  file  prior  to  transferring  data,  which  is  the  differ- 
ence of  the  starting  address  and  the  instantaneous  idle  address  at  the  time 
the  file  was  attached  to  the  subcontroller.  This  length  is  assumed  to  be  a 
uniformly  distributed  number  between  0 and  1023  and  the  time  required  to 
move  the  search  length  is  SL  (Search  Length)  x .8  Msecs.  The  average  of 
this  length  is  512  records  and  is  indicated  by  SL. 

Return  Length.  Once  the  subcontroller  has  conducted  its  assigned 
data  transfer,  it  must  return  the  file  to  the  control  of  the  idle  controller. 
It  must  first  align  the  file  with  all  of  the  other  files  controlled  by  the 
idle  controller  and  then  detach  itself,  thus  attaching  the  file  to  the  idle 
controller.  This  phase  of  a job's  execution  is  a function  of  the  size  of 
SL,  TL  and  the  number  of  rotational  locations  that  the  idle  controller  has 
moved  since  the  file  was  detached.  If  the  idle  controller  did  not  rotate  at 
all,  the  total  of  SL  + TL  4-  RL  (Return  Length)  would  always  be  an  integer 
multiple  (N)  of  1024,  which  is  the  file  length.  Instead,  the  sum  is  N x 
1024  + 5,  where  5 = T (time)/100  Msecs  because  the  rotational  stepping  rate 
of  the  idle  controller  is  one  step  per  100  Msecs.  The  total  time  of  SL+TL+ 
RL  if  N = 1 is  approximately  800  Msecs  (1024  x .8  Msecs)  and  would  therefore 
result  in  a 5 of  8 so  the  sum  of  SL  + TL  + RL  + S = 1024  + 8 = 1032,  or  less 
than  a 1 percent  increase.  Larger  values  of  N (the  largest  possible  value 
is  3)  and  conflicts  for  access  to  the  ECS  data  channel  cause  larger  values 
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of  6.  The  worst  case  value  is  72  and  results  a particular  file  is  6 required 
to  wait  for  access  to  the  ECS  data  channel  for  seven  other  maximum  length 
transfers  and  had  a SL  = TL  = RL  = 1024.  The  worst  case  value  of  6 results 
in  a 7 percent  increase.  Because  this  percentage  is  very  small,  future 
calculations  will  assume  6=0. 

ECS  Channel  Queuing.  Even  though  there  are  eight  AMS  subcontrollers 
simultaneously  executing  transfer  jobs,  only  one  channel  to  ECS  is  available 
for  the  transfer  of  data  and  all  data  must  be  transferred  over  this  channel. 
Tnis  ECS  channel  transfers  at  600  megabits  per  second,  which  is  a record 
transfer  rate  of  one  record  per  .8  psecs.  Access  to  the  channel  is  granted 
to  just  one  AMS  subcontroller  at  a time  on  a first-come  first-serve  basis. 

Coce  the  channel  is  granted  to  a subcontroller,  that  subcontroller  maintains 
the  channel  until  it  has  completed  its  transfer,  which  is  a function  of  the 
transfer  length.  After  the  completion  of  a transfer,  the  next  numerical 
subcontroller  requesting  the  channel  is  granted  it. 

When  a subcontroller  has  performed  the  job  of  positioning  its  file 
properly  for  a data  transfer,  it  requests  access  to  the  ECS  channel  in  order 
to  conduct  that  transfer.  If  the  channel  is  busy,  the  requesting  subcontroller 
waits  until  the  channel  is  available. 

AMS-CPU  Access  Conflicts.  The  ECS  controller  has  four  ports  which 
allow  access  to  the  ECS  storage  system.  In  the  PLATO  system  these  ports  are 
connected  to: 

1.  The  CPUs. 

2.  The  Distributed  Data  Path  (DDP ) , which  allows  direct  PPU  to 
ECS  transfers. 


3-  The  Side  Door  Adapter  (SDA)  which  allows  the  disks  to  communi- 
cate  directly  with  ECS. 

4.  AMS. 

The  DDP  and  SDA  can  be  neglected  with  regard  to  their  interaction  with  the 
A*s  and  CPU,  because  the  activity  in  these  units  is  very  small.  The  inter- 
action between  the  AMS  and  CPU  is  significant,  however,  and  results  in  what 
is  referred  to  as  AMS-CPU  ECS  Access  Conflicts,  to  be  discussed  later. 

In  the  PLATO  environment,  the  most  indicative  factor  concerning  the 
level  of  performance  of  the  AMS  controller  is  the  time  required  to  complete 
all  of  the  jobs  in  one  batch  since  all  of  the  transfers  related  to  a parti- 
cular user's  demand  would  be  packed  into  one  batch,  and  the  CPU  must  wait  or 
otherwise  engage  itself  while  that  batch  is  in  process.  In  addition,  even 
with  processing  overlapped  with  swapping,  the  average  time  for  swapping  ln 
and  out  must  be  less  than  the  average  process  time;  otherwise  the  CPU  will 
eventually  run  out  of  work  to  do.  A batch  contains  from  one  to  eight  jobs, 
With  each  job  having  its  individual  parameters.  The  parameters  of  each  job 
and  their  relation  to  the  parameters  of  the  remaining  jobs  determine  the 
time  required  to  completely  execute  a batch. 

For  a running  system,  it  will  be  shown  that  usually  only  the  execu- 
tion time  of  the  first  batch  among  several  will  be  important,  because  the 
average  time  required  by  the  CPUs  to  process  an  individual  user's  data  is 
longer  than  the  average  time  required  for  the  AMS  controller  to  execute  the 
batch  for  the  next  user.  The  AMS  controller  will,  therefore,  be  ahead  and 
continue  to  get  further  ahead  as  long  as  there  are  batches  to  do. 
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One  of  the  simplest  types  of  batches  is  one  containing  a single 
job,  and  this  batch  presents  a special  case  of  the  batch  process  model.  When 
the  AMS  controller  engages  in  a single  job  batch,  no  overlapping  can  be  em- 
ployed. The  batch  execution  time  is  simply  the  job  execution  time,  which  is: 

Time  (T)  = SL  + TL  + RL 

(Search  + Transfer  + Return) 

The  sum  of : 


SL  + TL  + RL 

must  be  an  integer  multiple  of  1024  records  if  the  rotation  of  the  idle  con- 
troller is  ignored.  The  integer  is  a function  of  TL  and  the  exact  relation 

between  the  starting  address  of  the  transfer  and  the  idle  address  when  the 
job  was  started.  If  the  file  is  positioned  at  a location  which  is  before  but 

not  within  the  area  that  is  to  be  transferred,  the  SL  will  be  that  distance 

to  the  beginning  of  the  transfer  area,  the  TL  will  be  the  transfer  length  and 
the  RL  will  be  (1024  - TL  - SL).  In  this  case,  the  integer  is  1.  If  the 
address  transferred  from  the  idle  controller  is  within  the  transfer  length 
area  of  the  file,  the  file  must  be  rotated  through  the  remainder  of  the  trans- 
fer length  and  around  to  the  beginning  of  the  transfer  area.  Then  TL  is 
cycled  through,  and  at  this  point,  more  than  one  complete  cycle  has  already 
been  completed.  The  RL  will  be  (2048  - SL  - TL)  and  the  integer  is  two. 

In  the  special  case  where  the  idle  address  is  very  close  to  the  transfer 
starting  address  and  the  TL  is  very  close  to  1024,  a total  of  three  revolutions 


32 


might  be  necessary  to  complete  a job.  The  SL  will  be  1024,  the  TL  is  1024, 
and  the  RL  is  1024.  The  integer  is  3. 

The  average  time  to  process  a single  job  batch  assuming  a uniform 
distribution  of  job  lengths  and  no  correlation  between  the  starting  address 
and  the  idle  address,  is: 

P(N=1)  x 819.2  + P (N=2)  x 2 x 819.2  + P(N=3)  x 3 x 819.2  Msecs 

where  P(N=x)  is  the  probability  that  the  number  of  cycles  equals  x. 

P(N=1)  is  the  probability  that  only  a single  rotation  will  be 
required,  which  is  the  probability  that  the  idle  address  falls  outside  of 
the  transfer  field.  If  we  assume  an  average  transfer  length  of  512,  we  have: 

P (N=l)  = TL/ 1024  = 512/1024  = .5 

P(N=2)  is  the  probability  that  two  rotations  of  the  file  will  be 
required  to  transfer  and  return,  which  is  the  probability  that  the  idle 
address  falls  within  the  transfer  field. 

P(N=2)  = (1024  - TL) / 1024  = 512/1024  = .5 

P(N=3)  is  the  probability  that  three  rotations  of  the  file  will  be 
required  in  order  to  process  a job.  This  condition  occurs  only  when  the 
idle  address  is  almost  exactly  the  same  as  the  transfer  .starting  address. 

Its  probability  is  very  samll  and  will  be  neglected. 

Therefore,  the  average  time  to  process  a single  job,  assuming  that 

no  other  jobs  are  competing  for  the  ECS  channel  and  the  CPU-AMS  conflicts  are 
negligible,  is: 
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T = .5  x 819.2  + .5  x 2 x 819.2  = 1230  ysecs 


More  typical  batches  encountered  in  normal  operation  of  the  AMS 
system  in  the  PLATO  environment  are  those  which  contain  more  than  ore  job. 

In  the  evaluation  of  these  more  complex  jobs,  additional  factors  need  to  be 
considered.  In  particular,  since  more  than  one  subcontroller  is  operational, 
only  the  access  time  to  the  first  job  will  be  of  concern,  and  the  queuing 
for  the  AMS-ECS  channel  will  be  dominant. 

The  overall  time  required  to  execute  a batch  is  determined  by  the 
sum  of  the  access  time  to  the  first  job,  total  time  to  transfer  and  the 
average  time  to  return  the  last  job  to  the  idle  controller.  Since  it  is 
assumed  that  there  is  no  correlation  between  the  idle  address  and  the  file 
starting  addresses  and  that  the  starting  addresses  are  randomly  placed,  the 
value  of  the  first  term  can  be  calculated  as  a function  of  the  number  of 
jobs  in  a batch  and  the  P (TL) . 

The  distribution  of  access  times  to  the  first  job  for  a uniform 
distribution  of  TL  can  be  shown  to  be: 


P(FSL)  = 


1023 

(TL/1024)  x n(l-TL/1024)  d(TL) 


0 


and  results  in  an  access  length  with  an  average  value  of  1024/ (n+1). 

For  non-uniform  distributions  of  access  times,  the  distribution  of 


P(FSL)  is: 


P(FSL)  = 


(■1023 

| (P(FL)  x n x (l-P(TL))  d (TL) 


0 
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In  the  case  of  a uniform  P(TL),  the  average  difference  between  the 
access  time  of  the  first  job  and  the  access  time  of  the  second  job,  which 
determines  the  amount  of  data  that  must  be  transferred  in  order  for  the  access 
time  to  the  second  job  to  be  covered  up  is: 

(1/n)  - (l/(n+l))  = 1/n  x (n+1) 

For  a batch  using  all  eight  subcontrollers,  the  average  access  to 
the  first  batch  is  1024/9  or  113  records  or  91  ysecs.  The  length  from  the 
access  to  the  first  job  to  the  second  job  is  14.2  records  or  113  words.  In 
the  PLATO  system,  the  minimum  usable  data  parcel  is  greater  than  400  words, 
and  therefore  a very  high  probability  exists  that  the  transfer  of  the  data 
from  the  first  job  will  completely  overlap  the  access  to  the  second  job. 

Once  the  first  job  has  been  accessed,  the  ECS  data  channel  is  the 
time-determinant  factor,  and  as  such,  the  sum  of  all  of  the  transfer  lengths 
enters  into  the  total  batch  time.  After  the  last  has  finished  with  the  data 
channel,  it  must  be  returned  to  its  idle  position  and  at  this  point  the  batch 
will  be  complete.  Ihare  is  no  overlapping  available  for  this  return  length; 
thus,  the  expected  value  is  simply  512  cycles. 

The  total  batch  time  therefore  is  as  follows: 

BT  = (1024/(n+l))  + (nxTL)  + 512  cycles 

if  the  minimum  transfer  length  is  1024/ ( (n+l)xn) . Table  2.1  shows  expected 
total  batch  time  and  minimum  transfer  lengths  to  maintain  high  AMS  efficiency 
as  a function  of  the  n and  TL.  These  numbeis  assume  that  the  distribution  of 
tj ansfer  lengths  is  uniform,  that  the  transfer  starting  address  is  uncorrelated 
to  the  idle  address,  and  that  the  transfer  addresses  are  randomly  located. 
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TABLE  2.1 

BATCH  TIMES  AND  MINIMUM  TL  (RECORDS) 


TL 

n 2 

3 

4 

5 

6 

7 

8 

100 

1053 

1068 

1116 

1182 

1258 

1340 

1425 

200 

1253 

1368 

1516 

1682 

1858 

2040 

2225 

400 

1653 

1968 

2316 

2682 

3058 

3440 

3825 

600 

2053 

2568 

3116 

3682 

4258 

4840 

5425 

800 

2453 

3168 

3916 

4682 

5458 

6240 

7025 

1000 

2853 

4768 

4716 

5682 

6658 

7640 

8625 

minTL 

170 

51 

34 

24 

18 

14 

11 

aThe 

total  amount  transferred 

is  the  TL 

x n. 

The  efficiency  of  the  AMS  controller  can  be  seen  by  calculating  an 
effective  access  time  which  is  the  difference  between  the  time  required  to 
actually  transfer  the  required  data  and  the  total  batch  time  divided  by  the 
number  of  different  files  transferred. 


Effective  Access  Time  (EAT)  = (BT  - (TLxn))/n 

When  the  transfer  lengths  are  subtracted,  the  effective  access 

time  is  only  a function  of  the  number  of  subcontrollers  active.  See  Table 

2.2. 


;-.x 
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TABLE  2.2 
EAT  vs.  n 


n 2 

3 

4 

5 

6 

7 

8 

EAT 

(cycles) 

426 

256 

179 

136 

109 

91 

78 

EAT 

(ysecs) 

341 

205 

143 

109 

87 

73 

62 

A parasitic  CPU  program  was  run  at  a different  control  point  from 
PLATO,  at  a higher  priority  than  PLATO,  and  used  the  student  bank  list 
supplied  by  PLATO  to  assemble  jobs  for  the  AMS  controller.  File  lengths  of 
512  words  were  used.  Since  the  parasitic  program  was  operating  at  a control 
point  above  PLATO,  all  of  the  time  spent  executing  this  logic  detracted  from 
the  time  available  to  PLATO.  Various  different  loads  were  tried  from  slightly 
over  100  users  to  over  220  users,  which  resulted  in  a variation  from  five  to 
eight  jobs  per  poll  on  the  average.  The  results  of  these  tests  are  shown  in 
Table  2.3. 


TABLE  2.3 
EMPIRICAL  DATA 


o K 

Users  Jobs/Batch  ms/Batch  Meas.  ms/Batch  Calc. 


116 

5.19 

1.50 

1 499 

120 

5.  77 

1.65 

1.522 

155 

6.04 

1.66 

1.535 

185 

7.15 

1.90 

1.625 

220 

7.87 

2.23 

1.934 

ms/Batch  Meas.  is  milliseconds  per  batch  measured. 
^ms/Batch  Calc,  is  milliseconds  per  batch  calculated. 
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The  measured  values  were  consistently  slightly  higher  than  the 
calculated  values,  which  indicates  some  degradation  due  to  the  CPU-ECS 
transfers.  If  reasonable  amounts  of  CPU  time  are  assumed  to  determine  the 
amount  of  ECS  data  channel  bandwidth  by  the  CPU,  (5  percent  at  116  users  to 
10  percent  at  220  users)  plus  an  additional  10  percent  for  the  ECS  bandwidth 
required  by  the  parasitic  test  program,  the  results  in  Table  2.4  are 
obtained. 


TABLE  2.4 

EMPIRICAL  DATA  VS.  CALCULATED  DATA 


Users 

Jobs/Batch 

ms/Batch  M 

ms/Batch  C 

Error 

116 

5.19 

1.50 

1.622 

7.5% 

120 

5.77 

1.65 

1.659 

.5% 

155 

6.04 

1.66 

1.688 

1.7% 

185 

7.15 

1.90 

1.813 

-4.8% 

220 

7.87 

2.23 

2.195 

-1.6% 

The  average  transfer  per  job  is  only  300  usees,  which  is  short  enough  to 
make  AMS  usable  even  for  short  jobs. 

Overall,  the  AMS  controller  proves  itself  to  be  entirely  usable 
in  the  PLATO  system  even  when  operating  with  only  short  jobs  and  would  be 
a usable  addition  to  the  memory  hierarchy. 


... 
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2.3.2  MEMORY  PERFORMANCE 

One  significant  problem  was  encountered  in  the  development  of  the 
AMS  memory  system.  This  problem  resulted  in  the  unacceptability  of  the  p- 
channel  MOS  shift  registers  in  the  application  due  to  excessive  device 
failure  and  poor  storage  integrety. 

More  than  17,000  integrated  circuits  are  assembled  to  construct 
a single  bank  of  AMS  memory  (262k  words).  Of  these,  one  device  comprises 
the  bulk  of  16,384  and  a second  is  used  in  a quantity  of  512.  These  two 
devices  also  accounted  for  almost  all  of  the  device  failures  encountered. 
The  modes  of  failure  of  the  two  devices  were  similar  and  took  two  forms: 

1.  Immediate  failure  upon  initial  insertion. 

2.  Failure  after  several  hours  of  operation. 

Failure  percentages  for  the  two  devices  are  tabulated  in  Table  2.5. 

TABLE  2.5 

DEVICE  FAILURE  STATISTICS 


Device 

Usage 

Failure 

(Initial) 

(Later) 

MM5013 

16,384 

420  - 3% 

610  - 4% 

MH0026 

512 

48  - 9% 

5-1% 

Once  the  assembly  and  testing  problems  were  overcome  and  the 
memory  could  be  fully  tested,  the  major  concern  was  total  reliability  of  the 
memory  system.  The  AMS  memory  was  designed  to  operate  in  the  PLATO  system. 
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and  since  this  system  services  almost  1000  users,  it  would  be  unsatisfactory 
for  any  memory  element  to  fail  except  on  very  rare  occasions.  The  memory 
section  of  the  AMS  memory  did  not  prove  to  be  capable  of  such  a high  level 
of  reliability.  The  reason  for  this  general  volatility  proved  to  be  inher- 
ent in  the  operation  of  the  P-channel  MOS  devices  used. 

The  basic  storage  element  within  the  P-channel  MOS  dynamic  shift 
register  is  a simple  capacitor.  Figure  2.2  is  a schematic  of  this  basic 
cell  and  shows  a capacitor  connected  between  the  substrate  and  the  gate  of 
the  transmission  gates.  This  capacitor  serves  as  the  storage  element  and 
is  refreshed  every  cycle  of  the  clock,  which  also  shifts  the  data  of  one 
cell  (shown)  into  the  next  cell  and  shifts  the  data  from  the  previous  cell 
into  this  cell.  The  implementation  of  the  capacitor  is  in  the  form  of  a 
reverse-biased  diode  junction,  which  has  a capacity  proportional  to 
and  has  a leakage  current  proportional  to  eT,  where  T is  the  temperature  of 
the  junction.  The  amount  of  time  that  data  is  stored  on  a capacitor  is  a 
function  of  the  capacity  and  the  temperature.  The  manufacturer’s  specifi- 
encion  guarantees  that  the  device  will  maintain  data  over  a frequency  range 
from  0.01  MHz  to  2.5  MHz,  corresponding  to  a cycle  time  of  from  100  Msecs 
to  0.4  psecs  over  an  ambient  temperature  of  0°C  to  70°C.  The  AMS  system 
j-imits  the  operation  of  the  devices  to  a range  of  100  Msecs  to  0.8  Msecs. 
However,  although  the  devices  are  rated  to  operate  over  this  range,  they 
will  not  reliably  operate  if  the  frequency  is  quickly  varied  from  one  extreme 
to  the  other.  The  reason  for  this  failure  is  as  follows. 
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Leakage  through  the  storage  capacitor  is  an  exponential  function 
of  the  temperature  of  the  junction.  At  slow  speeds,  the  temperature  of  the 
junction  is  very  low  (even  though  the  ambient  temperature  might  be  relatively 
high)  because  the  nearby  transistors  are  not  switching  very  fast  and  satu- 
rated MOS  transistors  dissipate  the  bulk  of  their  power  during  the  actual 
switching  function.  Since  the  capacitor  leakage  rate  is  low,  long  periods 
between  refreshes  can  be  tolerated,  as  is  true  during  low-speed  operation. 

At  the  other  extreme,  during  high-speed  operation,  the  temperature  of  the 
junction  is  quite  high  and  the  leakage  is  very  high  as  well.  However,  the. 
cell  is  refreshed  very  often  by  the  clock  and  so  data  is  maintained.  How-- 
ever,  when  the  data  rate  is  instantly  changed  from  a high  rate  to  a low 
rate,  the  temperature  of  the  cell  does  not  change  instantly,  and  for  a 
short  period  of  time  the  temperature  of  the  junction  is  high  but  the  refresh 
rate  is  low.  During  this  time  the  margins  are  greatly  reduced  and  an 
occasional  bit  is  dropped. 

This  problem  is  very  difficult  to  observe  carefully  and  as  such 
has  been  diagnosed  by  observation  and  through  discussions  with  engineers  of 
the  integrated  circuit  manufacturer.  No  mention  of  any  problem  of  this 
sort  is  contained  in  the  data  sheets  on  the  uses  of  the  device. 

The  purpose  of  this  work  was  to  discover  and  demonstrate  a new 
method  of  controlling  serially-organized  memories  in  such  a fashion  as  to 
make  them  usable  as  high-performance  swapping  memories  in  interactive  com- 
puter systems.  This  purpose  was  accomplished.  All  of  the  controller  tests 
and  evaluations  were  satisfactory  and  a great  deal  of  valuable  data  was 
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gathered  which  will  be  used  to  guide  future  AMS  projects.  Although  functional, 
the  actua1  memory  plans  used  in  thi^  research  would  require  error  correction 
and  detection  circuitry  for  sufficiently  reliable  operation  in  the  PLATO 
system.  Accordingly,  further  development  should  aw.iit  evaluation  of  more 
reliable  and  also  less  expensive  technology  which  are  now  becoming  available. 

P.  Tucker 
L.  Hedges 
1).  Anderson 


3.  PLATO  IV  TERMINAL  DEVELOPMENT 


Fabrication  of  the  second  prototype  has  been  completed  and  the  unit 
placed  into  operation  in  the  PLATO  IV  system.  The  prototype  terminal  is 
shown  in  Fig.  3.1a  while  Fig.  3.1b  shows  the  microcomputer  mounted  in  a drawer 
in  the  base  of  the  terminal. 

Work  is  proceeding  on  the  development  of  the  terminal  resident  pro- 
gram. This  program,  in  addition  to  emulating  the  existing  PLATO  terminal, 
has  been  expanded  to  include  the  following  additional  features: 

1.  Character  writing  in  both  vertical  and  horizontal  mode. 

2.  Character  writing  in  two  directions  in  both  horizontal  and 
vertical  modes. 

3.  Additional  character  formatting  functions  including  two  dyna- 
mically adjustable  margin  settings  and  two  dynamically  adjust- 
able tab  settings. 

4.  Incorporation  of  a boldface  character  set  (typeface). 

In  addition  to  the  above  resident  programs,  additional  programs 
have  been  developed  to  help  reduce  the  processing  load  on  the  central  computer. 
To  date  these  programs  include: 

1.  A local  animation  routine  which  performs  animation  sequences 
given  only  the  identity  of  the  object,  the  starting  and  ending 
points  and  the  rate  of  movement. 

2.  A circle  generation  routine  requiring  only  the  center  and  radius. 

3.  A compose  program  which  allows  the  user  to  store  messages  in  the 
terminal  and  later  call  them  up  for  display  as  a part  of  his 


program. 
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4.  A memory  dump  program  to  permit  the  contents  of  the  terminal 
memory  to  be  displayed  on  the  plasma  panel.  This  program  is 
used  primarily  for  debugging  purposes. 

In  April,  a parallel  panel  was  obtained  from  Owens-Illinois  and  has 
been  installed  in  the  terminal.  Software  has  been  developed  which  allows 
block  erase  of  user  specified  areas  of  this  panel  without  erasing  the  entire 
panel.  This  feature  requires  the  user  to  specify  two  xy  locations  and  the 
terminal  will  erase  (or  write)  the  area  specified  by  Ax  = x2  - x , and 

Ay  = y2  - yr 

A ROM  programmer  has  been  designed  and  built  for  use  in  generating 
new  terminal  resident  programs.  This  unit  which  attaches  to  the  terminal 
10  bus  can  program  a IK  x 8 bit  ROM  in  two  minutes.  Data  to  be  written  into 
ROM  is  first  loaded  into  the  terminal  RAM  memory  from  the  central  computer. 

The  data  is  then  transmitted  to  the  ROM  programmer  to  be  written  into  the 
ROM.  The  terminal  controls  the  rate  of  writing  into  the  ROM  as  well  as  reading 
back  the  data  for  validity  testing.  The  POM  programmer  is  shown  in  Fig.  3.2. 


J.  Stifle 

L.  Hedges 

M.  Hightower 


46 


4.  AUDIO  VISUAL  FACILITY 


4.1  RANDOM  ACCESS  AUDIO 

The  assembly  of  all  but  two  audio  units  awaiting  accessors  has 
been  completed,  thus  ending  the  University  of  Illinois  audio  production  pro- 
gram. All  future  random  access  audio  devices  will  be  obtained  from  indus- 
trial sources. 

An  order  for  102  random  access  units  from  E.I.S.,  Inc.,  has  been 
placed  and  a prototype  was  submitted  by  E.I.S.  for  our  inspection.  The 
audio  performance  exceeds  all  of  our  specifications  and  all  indications  are 
that  the  new  device  will  feature  improved  reliability  and  easier  operation. 

The  audio  disc  production  facility  has  been  steadily  supplying 
audio  discs  to  present  audio  users.  These  discs  are  of  the  same  size  as 
those  required  for  the  newer  audio  devices,  except  for  some  additional  holes 
that  can  readily  be  punched. 

4.2  RANDOM  ACCESS  SLIDE  SELECTORS 

A facility  for  maintaining  and  repairing  slide  selectors  has  been 
set  up  and  put  into  operation.  In  order  to  provide  uniform  alignment,  test 
and  repair  procedures,  a slide  selector  user's  manual  is  being  prepared. 

This  facility  will  also  be  responsible  for  maintaining  the  audio  devices. 

4.3  MICROFICHE  PRODUCTION 

Microfiche  production,  using  one  camera  for  square  and  another 
for  rectangular  formats,  is  expanding  with  increasing  numbers  of  users.  In 
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°rder  t0  dccrease  costs  and  microfiche  turn-around  time,  and 
increase  the  quality  of  color  reproduction,  CERL  has  ordered 
rolor  processing  system  for  processing  our  exposed  films. 


possibly  to 
an  automatic 


D.  Skaperdas 
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5.  HIGH  SPEED  MODEM  DEVELOPMENT 


5.1  INTRODUCTION 

A new  teachnique  for  high  speed  data  transmission  has  been  devel- 
oped and  modems  (MODulator/DEModulator ) have  been  designed  and  are  being 
tested.  The  purpose  of  this  investigation  is  to  provide  a new  and  less  ex- 
pensive media  of  multi-terminal  communication  between  the  computer  site  and 
a remote  site.  Utilizing  this  communication  technique,  9600  bits  per  second 
(bps),  enough  to  service  eight  terminals,  can  be  transmitted  on  a single 
voice  grade  telephone  line. 

9600  bps  modems  are  available  commercially  at  a price  of  approxi- 
mately $4000  per  end.  All  of  these  modems  exhibit  similar  characteristics 
in  that  they  are  generally  two  to  four  bits  per  baud,  2400  to  4800  baud 

modems.  This  is  to  say  that  data  elements  are  transmitted  at  2400  Hz  to 

4800  Hz  with  each  element  containing  from  two  to  four  bits  of  information. 

In  contrast,  the  transmission  technique  being  investigated  in  the  PLATO 

laboratory  involves  many  parallel  channels,  each  of  which  transmits  data 
elements  at  a 60  Hj:  rate,  and  each  data  element  contains  five  bits.  Thirty- 
two  data  channels  are  used  to  complete  the  9600  bps.  Two  additional 
channels  are  used  to  communicate  basic  timing  information  so  a total  of 
thirty-four  channels  are  used. 

Table  5.1  is  a general  detail  of  standard  design  voiceband  data 


channel . 
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TABLE  5.1 

STANDARD  DESIGN  VOICEBAND  DATA  CHANNEL 


Frequency  Response:  500-2500  Hz  (-2db  to  +8db) 

300-3000  Hz  (-3db  to  +12db) 
Envelope  Delay1:  1750  microseconds  (800-2600  Hz) 

1004  Hz  Response:  -12db  to  -20db  (18±4db) 

Noise  level  (C-raessage2) : -68  to  -40db  max3 

Signal/Noise  (1004  Hz  tone):  24db  min 

Single  frequence  interference:  3db  below  noise 

Frequency  Shift:  less  than  5 Hz 

Phase  Jitter:  no  more  than  10°  peak-to-peak 

Nonlinear  distortion:  2nd  harmonic  -25db  max 

3rd  harmonic  -30db  max 


Envelope  delay  is  defined  as  Af$/Af  * rate  of  phase 
change  with  respect  to  frequency  change. 

2C-message  is  a standard  weighting  curve  used  by 
phone  company  when  measuring  noise. 

The  maximum  allowed  noise  is  a function  of  the 
wire  miles  encountered  in  a line. 


Based  on  Table  5.1,  the  usable  telephone  bandwidth  ranges  from 
300-500Hz  to  2500-3000Hz  depending  on  the  tolerance  of  the  modem  equipment 
used  to  amplitude  and  envelope  delay  distortions.  All  of  the  presently 
available  modems  operating  at  2400  to  4800  baud  are  severely  effected  by 
the  envelope  delay  distortions  encountered  in  standard  lines.  This  is 
because  of  the  fact  that  the  delay  distortions  are  of  a significant  magni- 
tude when  compared  to  the  signaling  rates.  2400  baud  represents  one  signal 
per  417  microseconds.  All  high  baud  rate  modems  incorporate  a delay  equalizer 
(usually  a transversal  equalizer)  to  correct  or  flatten  the  phone  line  so  that 
the  modem  sees  very  small  differential  delays  over  the  bandwidth  of  the 


channel. 
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Another  characteristic  of  the  typical  phone  line  that  has  a severe 
degrading  effect  on  the  operation  of  high  baud  modems  is  the  presence  of 
impulse  noise.  Impulse  noise  is  that  noise  of  such  a nature  that  it  presents 
a spike  superimposed  on  the  normal  phone  line  signal  and  has  amplitudes  which 
are  comparable  to  the  data  signal.  The  duration  of  the  impulses  are  normally 
100-500  microsecond  in  duration.  The  presence  of  this  type  of  noise  will 
invariably  cause  an  instanteous  error  in  the  data  that  is  recovered  by  the 
modem  receiver  of  a high  baud  rate  modem  system.  This  is  because  the  dura- 
tion is  comparable  to  the  duration  of  the  data  signaling  element.  High  baud 
rate  modems  have  no  real  defense  against  impulse  noise  and  can  only  attempt 
to  recover  as  quickly  as  possible. 

The  modem  technique  that  has  been  developed  in  the  PLATO  laboratory 
is  very  tolerant  to  both  of  the  phone  line  distortions  listed  above.  The 
reason  for  this  is  the  fact  that  the  baud  rate  or  data  signaling  rate  of  this 
new  technique  is  only  60Hz  or  one  signal  element  per  16.7  milliseconds.  The 
magnitudes  of  the  envelope  delay  are  small  compared  to  this  as  is  the  typical 
duration  of  impulse  noise  hits.  The  new  modem  does  not  require  any  equalizer 
for  compensation  for  envelope  delay.  In  addition,  since  the  signaling  time 
is  16.7  milliseconds,  and  the  contents  of  the  phone  line  are  integrated  over 
this  period  of  time  to  determine  the  data  that  was  transmitted,  the  vast 
majority  of  the  impulse  noise  encountered  will  be  integrated  out. 

5.2  DATA  ENCODING  AND  TRANSMISSION 

Each  16.7  milliseconds  (60  times  per  second),  160  data  bits  must  be 
encoded  into  a complex  data  signaling  element  and  then  that  element  is 
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transmitted  for  the  next  16.7  milliseconds  while  a new  element  is  assembled. 
The  160  data  bits  are  grouped  into  32  sets  of  five  bits.  Each  of  the  sets 
are  used  to  determine  the  amplitude  and  phase  of  a single  frequency  carrier. 
There  are  32  carriers  used  to  communicate  data.  Since  the  absolute  phase  of 
a carrier  is  indeterminant  when  that  signal  arrives  at  the  receiving  end  of 
the  phone  line,  the  phase  and  amplitude  are  actually  determined  by  the  dif- 
ference (binary  subtraction)  of  the  data  transmitted  during  one  signaling 
elemert  and  the  next.  The  binary  data  transmitted  is  represented  by  the 
change  in  the  amplitude  and  phase  from  one  element  to  the  next.  Figure  5.1 
depicts  the  mapping  of  data  into  the  amplitude  and  phase  domain  (shown  as  x,y). 

The  composite  phor.e  line  waveform  consists  of  32  freouencies  which 
are  modulated  according  to  the  data  in  Fig.  5.1  plus  two  channels  which  are 
not  modulated  and  Instead  act  as  timing  pilots.  All  of  the  channels  are 
single  frequency  channels  and  the  frequency  of  those  channels  are  related  as 
multiples  of  63.75Hz.  The  lowest  frequency  is  eight  times  63.75Hz  or  510Hz 
and  the  highest  frequency  is  41  times  63.75Hz  or  2614Hz. 

Each  16.7  milliseconds,  the  phase  and  amplitude  of  each  of  the  32 
data  channels  is  updated  with  new  data.  The  16.7  millisecond  period  is 
divided  up  into  17  slots.  During  the  first  16  slots,  the  sum  of  all  Qf  the 
32  data  channels  plus  the  two  timing  channels  is  applied  to  the  phone  line, 
ihe  amplitude  of  the  composite  signal  is  adjusted  to  average  0dbm.  Figure 
5.2  shows  the  signal  which  is  applied  to  the  phone  line. 

The  entire  transmission  mechanism  is  implemented  digitally.  The 
phase  and  amplitude  modulation,  and  the  frequency  generation  and  summing  are 


all  digital  processes.  The  output  of  the  digital  summer  is  fed  to  a digital 
to  analog  converter  to  generate  the  complex  phone  line  signal. 

5.3  DATA  RECEPTION  AND  DECODING 

At  the  receiving  end  of  the  phone  line,  the  complex  composite  sig- 
nal that  is  presented  by  the  phone  line  must  be  interpreted  and  the  alue  of 
the  data  package  that  the  transmitter  encoded  to  generate  the  phone  line  sig- 
nal must  be  extracted.  Unfortunately,  the  phone  line  is  not  a perfect  trans- 
mission media  and,  therefore,  distorts  the  signal  transmitted  by  the  trans- 
mitter before  it  arrives  at  the  receiver.  The  major  types  of  distortion  that 
are  affected  are: 

1.  Amplitude  distortion  (both  uniformly  at  all  frequencies  and 
differentially  at  different  frequencies). 

2.  Phase  distortion  (envelope  delay). 

3.  Gaussian  noise. 

4.  Impulse  noise. 

5.  Frequency  shift  (all  frequencies  are  translated  by  a small 
amount) . 

6.  Non-linear  distortions  (harmonic  distortions). 

As  stated  earlier,  most  of  the  noise  and  phase  distortions  have  little  or  no 
effect  on  the  data  reception  due  to  the  fact  that  the  baud  rate  is  so  low 
(60  baud).  However,  the  amplitude  distortions,  the  frequency  shift  and  the 

non-linear  distortions  must  be  compensated  for  in  order  for  the  transmitteo 
data  to  be  recovered. 


The  frequency  domain  representation  of  the  transmitted  signal, 
taking  into  account  the  mluti-f requencies , the  modulation  at  60Hz  and  the 
pulsed  t 'nsmission  (Fig.  ...2)  consists  of  the  sum  of  34  signals  each  of 
which  appears  as  a sin(x)/x  shaped  distribution.  Figure  5.3  shows  the  shape 
.he  frequency  domain  signal  for  one  channel  and  Fig.  5.4  shows  the  com- 
posite phone  line  signal.  The  receiver  incorporates  34  filters  each  of  which 
is  shaped  like  Fig.  5.3  and  centered  on  the  individual  channels.  These 
filters  are  digitally  implemented  and  produce  the  values  of: 

r 16ms 

J sin(nwt)  v(t)  dt  = Y 

0 

and 

16ms 

cos(nwt)  v ( t ) dt  = X. 

. 

0 

The  value  of  'n'  varies  from  8 to  41,  the  value  of  w is  63.75/2tt.  The  process 

is  actually  a sampled  digital  one  and  the  sampling  rate  is  30.7kHz.  The 

values  of  'X'  and  'Y*  can  be  used  to  calculate  the  angle  of  the  carrier  within 

the  bandpass  of  the  filter  with  respect  to  the  sine  wave  by  the  relationship 
of : 


6 = Arctan  (X/Y) 

and  if  the  major  portion  of  the  energy  within  the  passband  is  the  energy  due 
to  the  transmitted  carrier  at  the  center  frequency  (f  ) of  the  filter  the 
angle  of  that  carrier  can  be  determined  and  thus  the  data  that  was  transmitted 


can  be  recovered. 
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In  order  for  the  modem  to  operate  properly,  the  exact  timing  of 
the  transmitter  must  be  recovered.  Since  the  filters  in  the  receiver  inte- 
grate over  a 16.7  millisecond  period,  this  interval  must  exactly  match  the 
interval  over  which  the  transmitter  transmits.  The  two  timing  channels  are 
not  modulated  and  are  therefore  usable  as  pilots  for  the  receiver  to  derive 
the  transmitters  timing  period.  In  addition,  since  the  phone  line  has  the 
possibility  of  shifting  all  of  the  frequencies  that  are  transmitted  by  as 
much  as  5Hz,  and  this  amount  of  offset  would  cause  a significant  amount  of 
phase  shift  on  all  channels  as  well  as  move  the  centers  of  the  filters  from 
the  centers  of  the  transmitted  carriers,  this  parameter  of  the  phone  line 
must  be  compensated  for.  One  of  the  timing  channels  is  used  to  derive  the 
frequency  offset  of  the  channel  and  this  information  is  fed  back  to  the  sine- 
cosine  generators  to  cause  those  generators  to  match  the  frequencies  of  the 
incoming  signals.  The  third  characteristic  of  the  phone  line  that  must  be 
taken  into  account  is  the  differential  amplitude  distortion.  All  of  the 
channels  are  computed  individually,  however,  and  a digital  decision  threshold 
feedback  is  incorporated  to  totally  account  for  this  characteristic.  All 
three  of  the  three  compensating  sections  mentioned  (timing  period  alignment, 
frequency  offset  and  individual  amplitude  thresholds)  are  interactive  and 
recursive  so  that  once  they  have  been  aligned  after  the  unit  is  first  turned 
on,  they  continue  to  maintain  themselves  while  data  is  being  transmitted  even 
if  the  phone  line  changes. 

A 7200  bit  per  second,  120  baud  unit  has  been  built  and  operated 
in  the  laboratory.  A 9600,  60  baud  unit  is  presently  being  constructed  for 
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testing  and  Is  expected  to  be  operational  In  the  third  quarter  of  1975. 
This  new  unit  will  Incorporate  the  knowledge  gained  from  the  7200  bps  unit 
as  well  as  several  new  innovations. 

D.  Bitzer 
W.  Keasler 
P.  Tucker 
M.  Hightower 
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6.  ADVANCED  TERMINAL  TECHNOLOGY  RESEARCH 

The  advanced  terminal  technology  research  program  is  concerned  with 
the  improvement  of  the  cost-performance  characteristics  of  the  man-machine 
interfaces  that  will  be  used  in  future  PLATO  systems.  The  activities  deal 
with  exploration  of  techniques  which  may  provide  near-term  improvement  of 
existing  terminal  related  hardv.are,  firmware  and  software  cost-performance 
characteristics,  and  with  exploration  of  totally  new  approaches  to  make  the 
man-machine  interface  more  efficient,  e.g.  to  improve  the  impedance  match 
between  machine  and  human  through  his  audio,  visual  and  tactile  senses.  Work 
is  being  carried  on  in  five  major  project  areas;  these  are: 

1.  Terminal  architecture. 

2.  Display  technology. 

3.  Audio  input  and  output. 

A.  Tactile  input. 

5.  Terminal-based  auxilliary  memory. 

6.1  TERMINAL  ARCHITECTURE 

The  objective  of  the  advanced  terminal  architecture  project  is 
two-fold.  First,  research  is  being  performed  to  support  the  design  of  the 
hardware,  firmware  and  software  for  future  processor-based  PLATO  terminals. 
Second,  research  is  being  conducted  in  order  to  evolve  a powerful  (yet  low 
cost)  laboratory  and  office  terminal  design  which  is  compatible  with  PLATO 
yet  exhibits  wide  ranging  multi-host  and  stand-along  capability.  Both  pro- 
jects are  being  carried  out  using  mini-  and  micro-computer-based  plasma 
display  terminals  developed  at  CERL. 
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6.1.1  SOFTWARE  FOR  PROCESSOR-BASED  TERMINAL  SYSTEMS 

Work  on  the  software  for  processor-based  terminals  has  yielded  the 
design  of  the  ICONIC1  System.  This  system  includes  specifications  for  soft- 
ware resident  in  the  central  computer  as  well  as  the  terminal.  To  fully 
identify  what  software  is  required  locally  requires  an  examination  of  what 
is  performed  centrally. 

Description  of  this  design  is  presented  under  three  headings: 

1.  Human  factors. 

2.  Software. 

3.  Hardware. 

Human  Factors.  The  design  rests  on  certain  assumptions  about  the 
uses  of  the  system  by  people.  These  assumptions  have  been  derived  from  a 
variety  of  sources,  including  data  on  the  PLATO  system.  A list  of  these 
sources  is  included  in  Appendix  A.  The  assumptions  are  listed  below. 

1.  People  can  perform  a sequence  of  muscular  actions,  spatially 
locate,  and  recognize  a pattern,  long  before  they  have  a name 
for  the  sequence,  location  or  pattern. 

2.  Individual  intellectual  work  is  usually  performed  as  part  of 

small  group  such  as  a class,  project  team  or  academic  depart- 
ment. 

3.  The  use  of  a properly  designed  iconic  notation2  for  information 

^mage  Construction,  Organization  and  Network  Interchange  Cloi.trol. 

The  symbols  in  notation  have  a physical  similarity  to  things 


represented. 
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stored  in  a data  base  would  allow  people  to  process  data  at 
rates  greater  than  1200  baud. 

4.  People  will  readily  accept  an  interactive  graphical  model  of 
something  as  a "description"  of  it. 

The  examination  of  man- machine  interaction  underlying  these  assump- 
tions has  yielded  a method  of  description  that  utilizes  graphical  models. 

Briefly  described,  this  method  consists  of  representing  the  inter- 
action with  a directed  graph.  The  nodes  are  images  (di  plays)  and  the  edges 
are  user  actions.  This  method  has  been  incorporated  in  the  ICONIC  system 
software. 

Software.  The  software  consists  of  system  routines  called  collec- 
tively the  "ICONIC  Designer",  and  applications  packages  called  "presentations". 
The  ICONIC  Designer  is  a generalization  of  the  TUTOR  editor  on  PLATO.  The 
Designer  is  used  to  create  presentations  analogously  to  the  way  the  editor 
is  used  on  PLATO  to  create  lessons. 

The  following  two  sub-sections  describe  some  of  the  distinguishing 
features  of  the  Designer  and  presentations. 

1.  ICONIC  Designer.  The  designer  prompts  the  user  in  performing 
two  operations.  They  are:  "Construct  an  Image"  and  "Construct 

a Control  Table". 

a.  Construct  an  Image.  This  choice  produces  a situation  like 
PLATO's  "SD"  option  in  the  editor.  However,  it  has  the 
additional  options  of: 
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(1)  Attaching  parameters  and  operators  to  the  image. 

(2)  Setting  those  parameters  and  inspecting  their  effect 
on  the  image. 

(3)  Modifying  image  by  "adding"  or  "subtracting"  other 
images . 

(4)  Moving  back  and  forth  through  an  image  like  a reel  of 
film  to  allow  insertions  and  deletions  to  image. 

b.  Construct  a Control  Image.  This  choice  allows  the  user  to 
complete  a table.  Such  tables  are  used  to  organize  the 
presentation  of  images  in  response  user  inputs.  The  format 
of  such  a table  and  the  method  entering  data  are  outlined 
in  Appendix  B. 

2.  Presentations.  A "presentation"  is  a collection  of  control 
tables  that  satisfy  references  among  themselves,  and  a collec- 
tion of  all  those  images  referenced  by  the  tables.  Presenta- 
tions are  best  thought  of  as  maps,  models  and  simulations. 

They  also  include  special  designers.  They  allow  a user  to 
"move  through"  or  examine  various  Images  which  in  turn  repre- 
sent data  in  computer  or  the  state  of  some  other  physical  system. 
Hardware.  The  hardware  organization  reflects  the  division  of  soft- 
ware into  two  main  classifications.  The  central  computer  contains  the 
Designer  and  is  used  very  interactively  during  the  design  of  presentations. 

The  peripheral  processor  controls  most,  if  not  all,  of  user  interaction  with 
presentations.  For  many  applications,  a communications  between  the  central 
computer  and  the  peripheral  pro cess or /memory  would  not  be  necessary. 


*■  II.  1.1  P U!  iui 
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Appendix  D contains  a schematic  representation  of  the  network. 

The  display  controller  represents  key  compromise  between  the  extremes  of 
total  centralization  as  embodied  by  PLATO  and  a collection  of  toally  auto- 
nomous mini-computers.  It  can  also  be  seen  as  a generalization  of  the  in- 
telligent terminal. 

The  Display  Controller  is  the  heart  of  the  ICONIC  system  since  it 
handles  the  bulk  of  human  interactions  with  the  system.  The  disk  memory 
memories  attached  to  each  controller  give  the  ICONIC  system  a massive  dis- 
tributed memory  system  which  is  competitive  with  the  ECS  of  the  PIATO  system. 
The  "slowness"  of  the  disk  medium  is  compensated  for  by  the  samll  number  of 
terminals  accessing  it.  The  resulting  tradeoff  yields  a system  which  can  be 
more  responsive  to  user  input  than  PLATO. 

The  use  of  the  Display  Controller  also  allows  the  ICONIC  system  to 
be  implemented  with  a greater  variety  of  computers,  than  is  possible  with 
PLATO.  This  greater  adaptability  appears  to  be  more  valuable  than  the  vir- 
tually unlimited  communications  capability  of  a totally  centralized  system. 

6.1.2  PROCESSOR-BASED  TERMINAL  SYSTEMS 

A form  of  the  pdpll  based  terminal  has  been  assembled  on  an  experi- 
mental basis  for  use  with  a large  information  retrieval  system.  The  main 
data  base  resides  on  MULTICS  (Mass.  Inst,  of  Tech.)  and  is  accessed  through 
the  ARPA  net  node  at  the  Center  for  Advanced  Computation  on  campus. 

The  hardware  configuration  is  a pdpll/05  with  22K  of  memory, 
parallel  plasma  display,  keyset,  touch  panel  and  DL11  programmable  serial 
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communications  interface.  A dual  DEC  tape  drive  is  used  for  program 
storage. 

The  design  goal  of  the  system  is  to  demonstrate  the  advantages  of 
a local  processor  and  graphics  display  on  an  information  retrieval  system. 

Once  the  system  is  initialized,  the  touch  panel  is  the  only  input  device. 

Part  of  the  data  base  is  loaded  from  the  host  and  stored  locally.  This 
local  data  base  is  automatically  updated  as  needed.  If  the  link  to  the  main 
system  is  lost,  the  local  program  can  continue  to  format  and  display  all  of 
the  local  data  base,  while  also  informing  the  user  of  the  status  of  the 
communications  link.  When  the  link  is  restored,  the  program  can  return  to 
using  the  entire  data  base  without  reinitialization. 

Work  is  continuing  on  the  feasibility  of  local  word  storage  to 
increase  text  writing  speeds.  It  had  been  decided  to  analyze  the  PLATO 
system  output  stream  to  determine  character  and  word  frequencies.  The  pro- 
gram to  determine  character  frequencies  has  been  completed,  and  the  one  to 
determine  word  frequency  distributions  is  near  completion. 

While  it  is  still  not  clear  how  much  would  be  gained  in  visual 
speed  improvement  by  storing  words  at  the  terminal,  a number  of  inefficiencies 
in  the  current  method  of  sending  text  have  been  quantitatively  analyzed.  For 
example,  both  the  need  for  a null  character,  and  the  advantage  of  keeping 
more  local  positioning  information  such  as  margins  has  been  found  to  be  quite 
significant . 

More  work  will  be  done  to  improve  the  character  by  character  sending 
of  text,  both  from  the  standpoint  of  display  speed  and  in  reducing  the  amount 
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of  processing  needed  to  convert  from  the  system's  internal  character  repre- 
sentation to  the  terminal  format. 

A modification  of  the  PLATO  IV  terminal  simulator  is  currently 
running  under  a version  of  RT11,  Digital  Equipment  Corporation's  disk  operat- 
ing system  for  the  pdpll.  This  system  now  uses  the  RK-05  cartridge  disk, 
but  will  convert  to  floppy  disk  as  soon  as  the  necessary  software  arrives 
from  DEC.  The  main  emphasis  of  this  system  is  image  trapping,  which  allows 
a user  to  create  a display  on  PLATO,  send  it  to  the  pdpll  as  a stream  of 
terminal  commands,  which  are  then  stored  and  regenerated  locally.  The  com- 
bination of  image  trapping  of  text  and  diagrams,  plus  local  area  erasure 
(block  erase)  are  being  used  with  a medical  information  system  that  the  user 
can  interact  with  at  acceptable  speeds.  (1/3  sec.  for  a full  screen  rewrite. 

Many  applications  which  involve  sending  data  to  PLATO  IV  have  been 
found.  For  example,  sending  grey  scale  pictura  information  that  has  been 
digitized  elsewhere  to  PLATO  for  use  in  lessons  there,  or  adding  binaries 
assembled  for  the  pdpll  on  a more  convenient  system  to  those  currently  stored 
on  PLATO.  Also,  laboratory  terminals  need  to  send  experimental  results.  We 
now  have  two  programs  which  do  this,  with  enough  error  checking  to  prevent 
data  loss.  One  dumps  a core  image,  the  other  accepts  data  from  the  serial 
communications  line,  buffers  it  as  necessary  and  sends  it  to  PLATO. 

Sending  data  back  to  PLATO  in  this  manner  is  non-trivial  since  the 
problem  of  low  bandwidth  is  compounded  by  the  system  wide  assumption  that 
most  input  is  hand  time  slices.  We  are  encouraging  a system  level  change 
both  in  priority  structure  and  in  the  TUTOR  language  to  help  alleviate  this 


problem. 


6.2  DISPLAY  TECHNOLOGY 

The  primary  objective  of  the  display  technology  project  is  to 


enhance  the  performance  and  minimize  the  cost  of  the  display  systems  which 
are  used  in  PLATO  system  terminals.  At  present,  there  are  two  principle 
activities: 

1.  Advanced  plasma  display  system  research. 

2.  A study  of  basic  display  device  principles. 

6.2.1  PLASMA  DISPLAY 

During  this  period,  a study  of  second  generation  PLATO  terminal 
display  design  alternatives  was  continued.  It  is  expected  that  this  activity 


will  continue  throughout  the  next  period. 

t I 

6.3  TACTILE  INPUT  SYSTEMS 
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Since  CAI  is  necessarily  a highly  interactive  environment,  the 

i 

PLATO  system  draws  much  of  its  instructional  power  from  the  graphics  oriented 


plasma  display  terminal.  The  efficiency  of  the  system  relies,  in  part,  on 


the  efficiency  of  the  man-machine  interface  provided  for  at  the  terminal. 


The  keyset  has  always  served  as  the  standard  tactile  input  to  a computer 


terminal.  However,  manipulation  of  graphically  formated  display  material 


is  particularly  tedious  when  the  keyset  is  the  only  means  of  data  entry 


available.  This  is  a distinct  disadvantage  when  the  effects  of  limited  stu- 


dent attention  span  are  considered.  A more  direct  means  of  addressing  display 
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material  can  be  had  by  incorporating  a position  sensitive  device  overlaid 
on  the  display  surface. 

A crossed  light  beam  position  encoder,  developed  at  CERL,  has 
successfully  met  the  PLATO  IV  system  requirements  of  low  cost  and  simple  user 
operation.  This  touch  panel  has  a resolution  of  four  bits  per  axis  (16  x 16 
touch  sensitive  areas)  and  a limited  rate  of  data  generation  as  constrained 
by  the  low  bandwidth  return  path  of  the  PLATO  IV  communications  network. 

While  the  crossed  beam  technique  affords  absolute  resolution  (i.e.  the  beams 
are  fixed  in  space),  this  resolution  is  limited  by  the  physical  size  of  the 
discrete  transducers  used  to  emit  and  to  detect  the  light  beams. 

The  development  of  a minicomputer  based  intelligent  terminal  at 
CERL  that  has  local  computing  capability  and  storage  stimulated  interest  in 
designing  a second  generation  graphics  input  device  that  could  more  fully 
utilize  this  increased  data  handling  capacity.  Greater  resolution  of  eight 
bits  per  axis  (256  x 256  touch  sensitive  areas)  and  position  encoding  rapid 
enough  to  follow  hand  drawing  in  real  time  were  major  changes  in  design 
objectives.  It  was  felt  important,  however,  that  the  additional  touch  cap- 
ability not  be  gained  at  the  expense  of  operational  simplicity.  During  the 
reporting  period  a prototype  transparent  conducting  glass  touch  entry  system 
was  designed  and  built  in  an  effort  to  meet  these  specifications. 

Initially,  attempts  were  made  to  adapt  an  existing  commercial  pro- 
duct into  the  design  in  order  to  more  quickly  expose  a working  graphics  tablet 
to  the  CERL  courseware  staff.  This  was  done  primarily  to  create  constructive 
feedback  from  those  who  could  use  the  device.  Although  the  resulting  unit 


worked  well  enough  to  demonstrate  the  principles  of  operation,  performance 
of  the  hybrid  system  proved  unsatisfactory.  Emphasis  was  then  shifted  toward 
designing  a completely  in-house  prototype  that  could  be  more  easily  modified 
to  experiments]  specifications. 

The  graphics  encoder  is  built  around  a glass  substrate  coated  with 
a conducting  thin  film  that  exhibits  linear  planar  resistive  properties.  The 
thin  film  is  typically  composed  of  stannous  oxide  applied  with  well  established 
vapor  deposition  processes.  A major  step  in  the  proposed  design  evolution  is 
the  integration  of  the  thin  film  with  the  plasma  display  itself,  the  display 
glass  serving  as  the  substrate.  This  step  will  provide  for  a minimum  of 
parallax  and  attenuation  in  the  resulting  display  device. 

A significant  feature  of  this  design  is  the  use  of  a transparent 
metalized  membrane  closely  overlaid  above  the  active  area  of  the  graphics 
encoder.  The  conductive  membrane  acts  as  a two-dimensional  probe,  thus 
eliminating  the  need  for  an  active  hand-held  stylus  and  connecting  wire. 
Additionally,  the  overlay  acts  as  a barrier  against  adverse  environmental 
conditions,  preventing  oil  and  dirt  accumulation  on  the  active  surfaces  and 
protecting  the  more  expensive  coated  glass  from  scratches.  It  should  be 
noted  that  resolution  is  not  limited  by  the  contact  area  between  the  membrane 
and  thin  film  coating.  There  is  the  future  possibility  of  back  coating  the 
plastic  polarizer,  already  required  for  plasma  displays,  thus  increasing  the 
transmission  efficiency  of  the  composite  system.  These  advantages  are  parti- 
cularly suited  to  the  requirements  of  operating  ease  and  low  maintenance. 


To  visualize  how  position  is  determined,  consider  current  flowing 
through  one  axis  of  the  thin  film  coating.  This  current  will  create  equi- 
potential  lines  that  are  orthogonal  to  the  current  flow.  A probe  touching 
the  conducting  surface  at  some  point  will  assume  a voltage  that  is  directly 
proportional  to  the  position  of  the  probe  on  the  axis  parallel  to  the  current 
flow.  This  voltage  is  then  digitized  to  provide  a binary  representation  of 
the  (x,y ) position.  This  scheme  offers  high  resolution  inherent  in  the  con- 
tinuous nature  of  the  thin  film. 

The  control  logic  in  the  encoder  accepts  mode  select  and  variable 
length  comparator  commands  from  the  terminal  under  program  control.  The 
mode  may  be  chosen  either  to  cause  the  hardware  to  generate  a single  coordi- 
nate per  touch  or  to  generate  a stream  of  coordinates  as  long  as  the  overlay 
is  in  contact  with  the  resistive  surface.  The  digital  comparator  checks  the 
last  converted  coordinate  with  the  newest,  preventing  the  transfer  of  data 
to  the  terminal  in  the  event  that  the  two  data  words  are  equivalent.  Compara- 
tor precision  is  program  selectable,  allowing  the  graphics  encoder  to  operate 
at  reduced  resolution  while  still  eliminating  the  need  for  the  programmer  to 
check  for  redundant  data. 

At  this  time  the  unit  has  not  been  fully  tested  due  to  a delay  in 
the  acquisition  of  high  quality  coated  glass.  Work  yet  to  be  completed  in- 
cludes fabrication  of  a suitable  mechanical  frame,  cost  and  performance  con- 
scious modifications  and  evaluation  of  the  fully  operational  encoder.  Of 
particular  interest  in  performance  tests  are  linearity,  long  term  stability 
and  the  effects  of  noise  on  the  system.  These  tests  are  important  because 
accuracy  and  absolute  resolution  depend  on  these  factors. 
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6.4  AUDIO  INPUT  AND  OUTPUT  SYSTEMS 

The  terminal  technology  research  group  has  two  current  programs  in 
audio  input/output  systems.  One  activity  deals  with  the  investigation  of  a 
terminal-based  speech  recognition  scheme  which  will  lend  itself  to  low  cost 
production,  and  which  can  be  used  with  the  low  bandwidth  return  path  to 
PLATO.  The  second  activity  deals  with  the  evaluation  of  a commercially  avail, 
able  tape  cassette  system  which  can  be  used  in  conjunction  with  a standard 
PLATO  terminal. 

6.4.1  VOICE  INPUT 

The  major  emphasis  of  our  audio  input  work  has  been  on  the  imple- 
mentation and  evaluation  of  modifications  to  our  existing  speech  recognition 
hardware  and  software,  in  an  attempt  to  both  improve  recognition  reliability 
and  reduce  the  amount  of  information  sent  to  the  PLATO  computer. 

A considerable  amount  of  time  was  spent  trying  to  correct,  incon- 
sistencies that  were  noted  in  the  results  of  our  initial  performance  evalua- 
tion tests.  It  was  hypothesized  that  keys  were  being  dropped  due  to  auto- 
matic interrupts  occurring  during  key  processing,  resulting  from  the  high 
CPU  usage  of  the  recognition  program.  To  guard  against  this  possibility, 
it  was  decided  to  utilize  a handshaking  scheme  between  the  voice  input  and 
the  CYBER  70.  The  system  utilizes  an  external  output  word  (rather  than  the 
terminal)  to  generate  a data  resume.  To  check  for  keys  being  dropped,  the 
finish  key  was  modified  to  send  a count  of  the  number  of  keys  generated  to 
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be  compared  with  the  number  of  keys  received.  It  has  been  found  that  keys 
are  still  being  dropped  at  about  a one  percent  rate,  which  is  probably  low 
enough  to  leave  performance  relatively  unimpared.  Nevertheless,  minor  i„- 

consistancies  are  still  being  noted  probably  due  to  inherent  statistical 
variation. 

A number  of  modifications  have  been  implemented  but  evaluation  of 

their  effect  has  been  delayed  due  to  the  performance  evaluation  difficulties 
mentioned. 

First  implemented  was  hardware  to  allow  different  thresholds  for 
different  measurement  types.  It  does  appear  that  varying  Individual  thres- 
holds can  improve  performance.  A series  of  tests  will  be  run  to  determine 
an  optimal  set  of  threshold  values. 

Second  was  a system  that  causes  keys  to  be  generated  only  if  the 
difference  threshold  is  exceeded  on  two  consecutive  sampling  passes  (rather 
than  one  with  current  system).  Initial  results  indicate  that  relatively 
significant  savings  do  occur  without  serious  reduction  in  recognition  ability. 

The  third  modification  implemented  is  a "finish  key"  that  is  gen- 
erated at  the  end  of  an  utterance  (.5  seconds  after  the  input  signal  falls 
below  the  noise  threshold).  This  key  eliminates  the  need  of  a speaker  to 
remain  quiet  until  all  the  keys  are  transmitted  as  is  currently  the  case,  and 
it  contains  a six  bit  measurement  of  the  duration  of  the  utterance,  providing 
a more  accurate  duration  indication  than  is  currently  possible. 

Some  exploration  of  software  improvements  was  also  carried  out.  A 
series  of  tests  were  run  to  evaluate  the  effect  of  using  different  sets  of 
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b-weights  for  different  vocabularies.  The  results  we  obtained  did  not  indi- 
cate that  there  were  significant  gains  in  recognition  with  the  b-weights 
calculated  by  our  correlation  methods. 

Some  exploration  of  the  difference  between  linear  and  hyperbolic 
prediction  methods  was  also  carried  out.  There  was  not  sufficient  difference 
between  these  two  methods,  though,  to  warrant  further  efforts  in  this  area. 

Our  current  work  involves  implementing  further  modifications  and 
evaluation  of  the  existing  ones. 

6.5  AUXILLIARY  MEMORY  SYSTEMS 


In  the  consideration  of  micro  and  mini-computer-based  terminal 
systems  on  PLATO,  a natural  requirement  is  that  of  additional  low-cost, 
terminal-based  memory  for  storage  of  expanded  character  sets,  storage  of 
image  frames,  storage  of  local  programs  for  management  of  lab  and  office 


systems  and  storage  of  terminal  operating  systems  for  multi-host  operation. 


Current  activity  in  this  area  is  concentrated  on  evaluation  of  floppy  disk 
technology  and  low  cost  solid  state  shift-register  memory  systems. 
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7.  OPERATIONS 

The  PLATO  IV  Operations  Group  has  responsibilities  in  the  following 
areas:  installation,  maintenance,  microwave  and  data  line  communications. 

The  group  also  supplies,  on  occasion,  technical  support  for  demonstrations. 

7.1  INSTALLATIONS 

During  this  period,  equipment  from  Ft.  Monmouth  was  transferred 
and  the  site  at  Stanford  University  was  closed.  The  installation  of  four 
terminals  and  associated  4800  baud  equipment  at  Ft.  Belvoir,  Virginia  on 
May  1,  1975  and  at  Maxwell  AFB  on  June  9,  1975  completed  the  original  ARPA 
98  terminal  system.  In  the  coming  months,  we  anticipate  reinstallations  as 
presently  installed  equipment  is  reassigned. 

7.2  MAINTENANCE 

The  maintenance  operations  consist  of  two  separate  but  intercon- 
nect j.ng  areas:  the  physical  repairing  of  non-working  terminals  and  the  re- 

pairing of  the  parts  that  have  been  replaced.  The  diagnosis  of  a particular 
problem  is  either  done  by  personnel  at  the  site  or  in  consultation  with 
engineers  at  CERL.  This  interexchange  of  information,  either  by  terminal  or 
telephone,  has  proven  to  be  a valuable  means  of  reducing  the  down  time  of 
equipment  as  well  as  improving  the  ability  of  on-site  personnel  to  do  their 
own  troubleshooting.  This  has  menat  that  the  physical  repairing  of  the 
terminals  can  be  accomplished  by  sending  replacement  parts  to  the  site, 
where  physical  replacement  is  then  made.  The  number  of  trips  required  by 
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CERL  personnel  to  the  sites  has  been  greatly  reduced,  thus  lowering  the  cost 
of  maintenance.  This  has  worked  particularly  well  at  San  Diego,  Aberdeen 
and  Sheppard,  where  extremely  helpful  and  qualified  personnel  exist.  We  are 
continuing  to  supply  all  the  maintenance  for  Chanute  AFB. 

As  was  reported  earlier,  a new  repair  program  was  put  into  service 
on  June  1,  1975.  Figure  7.1  shows  an  actual  report.  The  first  section  con- 
tains all  the  information  needed  to  identify  the  terminals  and  locations. 
Section  2 gives  the  reporter's  diagnosis  of  the  problem.  On  observing  this 
report  a CERL  engineer  contacts  the  site  and  follows  through  until  the  termi- 
nal is  confirmed  as  being  operational.  This  procedure  is  noted  in  Section  3, 
repair  comments.  The  checklist  in  Section  4 is  used  to  call  attention  to 
specific  areas  of  trouble.  Should  the  problem  be  related  to  the  plasma  panel 
or  power  supply,  then  notations  are  made  in  the  report  as  shown  in  Fig.  7.2. 
Once  the  terminal  is  verified  as  operational,  the  status  is  changed  to 
"Finished"  at  which  point  the  down  time  clock  stops.  The  total  down  time 
is  recorded  just  below  the  checklist.  The  status  change  as  well  as  other 
types  of  changes  are  made  by  use  of  Section  5.  When  the  defective  component 
is  repaired  at  CERL,  the  final  report  comments  are  made  by  the  repairman  in 
a section  shown  in  Section  6,  which  appears  in  place  of  Section  5.  The  new 
repair  program  has  proven  much  more  satisfactory  than  its  predecessor,  how- 
ever, we  are  presently  updating  it  to  provide  for  easier  entry  of  comments  by 
repair  personnel.  These  changes  will  be  reported  in  a future  report. 
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Repaired  In  Field  01  (CERL) 

*•  voltage  adjustment  d.  display  electronics 

b.  fuses  & components  e.  power  supply 

c.  other  f.  glass 


SECTION  1 


Updated-F  report  from  Remote 

Terminal  5.02 

F ror.i  b 1 dg  501,  rm3 , ma>we  11  a f b 
Reoorted  by  bl  abbot t 


site 

Phone  - 2052936 122 
of  mtc  site  25  stn. 


r in  * 
10372 


SECTION  2 


Reporter  comment s : 


! *'■' yr-  1 1 n'=>  that  appears  on  the  screen,  also  appears  on 
ei  .her^  lines  29  and  30  (eg)  all  garbled  up.  doesnt  appear 

j *2  ‘2^  l=,~^  ^ut  m-=»ybe  in  the  screen  electronics.  happen 

1 at  this  terminal  onlu 


SECTION  3 

Repair  comments; 

terminal  has’  a bad  md30  panel,  verified  bad.  pp  4 3^25 4 
new  panel  will  be  sent  jhk  6/27/75/packed  6/30/sent  7/3  lb 
sent  pp430U0,  def  unit  rec  cerl  7/21/75  jhk 


i£  O 


SECTION  4 


O-ECKLIST 

a.'  plasma  panel  «-  b)  panel  power  c)  logic  card 

d,<  logic  power  e)  terminal  elec.  f)  keyset 

i;.  slide  sel.  h)  touch  panel  i)  audio 

j)  phone  line  * k.)  cmr4  1)  ‘other  * 

eoorted  on  26  }un  1975  at  7.76  hours  Total  Down  Time 

c .ple-ed  14  Ju  17  1 975  at  15.40  hours  13.32  days 


SECTION  5 


* s 2 = Complete  i = Finished 

4 - x n-_  ..mp  1 et  e 5 = Info  onlv  6 = Update:!  Finished 
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SECTION  6 
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Table  7.1  shows  an  analysis  of  the  repair  program  for  the  last 
reporting  period.  It  also  shows  that  the  following  repairs  and  trips  were 
made  at  the  ARP  A sites.  When  examining  the  Lable,  one  should  be  aware  that 
a typical  time  for  shipping  a part  and  installing  same  is  9 days  and  a 
terminal  is  considered  down  (according  Lo  PLATO  Operations  people)  from  the 
Lime  it  is  reported  in  repair  until  it  is  verified  as  operational  by  someone 
at  the  site.  The  down  times,  therefore,  include  the  time  to  ship  and  install 
the  defective  part.  Table  7.1  also  shows  higher  down  times  for  those  sites 
where  no  personnel  are  available  for  troubleshooting  and  repair.  The  second 
greatest  time  builder  is  time  required  to  send  a man  to  a site  for  repairs. 
Finally,  telephone  line  problems  on  weekends  and  lack  of  available  part  re- 
placements add  to  the  down  time  for  terminals.  It  is  hoped  that  the  telephone 
line  analyzer  described  later  in  this  report  will  dec -ease  the  time  needed  to 
diagnose  line  problems  and  thus  reduce  the  total  down  Lime. 

7.3  Ml CKOWAVL  SERVICE 

On  April  5,  1975,  the  temporary  microwave  system  on  MDS  Channel  1 
was  replaced  with  a permanent  system  operating  on  MDS  Channel  2A.  This  six 
mhz.  change  required  replacement  of  the  transmitter  and  down  converters. 

To  eifectively  monitor  the  microwave  system  performance,  a combina- 
tion software/hardware  fault  reporting,  system  has  been  developed.  Every 
fifteen  minutes  a software  routine  <becks  the  transmission  errors  for  each 
microwave  site.  If  the  error  rate  exceeds  10  errors  per  1000  keys,  a signal 
from  the  computer  is  sent  to  a visual  display  connected  to  the  computer 
operator  terminal.  The  operator  will  then  notify  repair  personnel. 
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7.4  COMMUNICATIONS 

The  Operations  Group  is  responsible  for  all  communications  connec- 
tions between  CERL  and  PLATO  IV  terminals.  In  the  case  of  ARPA  installation, 
all  telephone  lines  are  ordered  through  Washington,  however,  in  fact,  the 
information  as  to  specifications  comes  from  Urbana. 

The  storing  of  information  pertaining  to  telephone  lines  and  loca- 
tions has  become  a burden  of  such  magnitude  as  to  cause  the  creation  of  a 
computer  program  to  keep  track  of  all  the  information  needed.  This  program 
is  nearing  completion  and  will  be  described  in  a later  report. 

7.5  DEMONSTRATIONS 

The  Operations  Group  provided  support  for  two  ARPA  demonstrations 
during  the  last  quarter,  however,  no  trips  were  required. 

7.6  EQUIPMENT  DESIGN 

Although  designing  of  equipment  is  not  the  principal  function  of 
the  Operations  Group,  we  have,  in  the  past,  developed  test  equipment  to 
assist  in  the  maintenance  operation.  The  keyer  described  in  a previous 
report  has  been  modified  and  an  additional  unit  constructed.  A fault  reporting 
system  was  developed  and  constructed  as  described  in  the  section  on  microwave 
service.  Also  designed  and  under  construction  is  a communications  line  ana- 
lyzer and  a time-shared  data  switch  which  is  constructed  and  operational. 


7.6.]  LINE  ANALYZER 


An  inexpensive  test  instrument  has  been  recently  disigned  which  will 
allow  remote  PLATO  users  to  monitor  and  test  their  data  lines.  The  test  in- 
strument called  the  PLATO  Line  Analyzer  consists  of  a digital  frequency 
counter,  an  A.C.  digital  voltmeter  and  test  tone  oscillator.  The  frequency 
counter  will  measure  from  zero  to  9,999  Hz.  The  A.C.  voltmeter  will  measure 
levels  from  40  mv  (-29  dbm)  to  6v  (+9  dbm) . The  test  oscillator  is  preset 
to  1 KHz  at  0 dbm.  It  is  hoped  that  the  cost  can  be  kept  low  enough  so  that 

all  sites  can  obtain  this  unit  to  assist  in  communication  problems  trouble- 
shooting. 

7.6.2  TIME-SHARED  DATA  SWITCH 

There  are  occasions  where  it  is  advantageous  to  be  able  to  serve 
more  than  four  terminals  with  one  4800  baud  modem  multiplexer.  To  solve  this 
problem,  a data  switch  has  been  designed.  The  switch  permits  the  operation 
of  either  a local  terminal  (one  in  the  same  vicinity  as  the  multiplexer), 
and/or  a remote  terminal.  The  remote  terminal  can  be  connected  by  either  a 
dedicated  telephone  line  or  an  auto  answer  modem.  Although  they  effectively 
share  the  same  port,  the  local  terminal  always  has  priority  of  use.  The 
design  is  being  modified  to  allow  the  local  user  to  know  if  the  remote  termi- 
nal is  operating.  The  data  switch  is  shown  in  Fig.  7.3, 

7.7  COPIER  MAINTENANCE 

Varian  electrophotographic  hard-copy  devices  have  been  installed  and 
placed  in  operation  at  the  following  ARPA  sites: 
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Aberdeen  Proving  Grounds 
Lowry  A.F.B. 

San  Diego  Naval  Station 
Sheppard  A.F.B. 

Chanute  A.F.B. 

Orlando  Naval  Training  Center 

At  each  site  an  operator  has  been  trained  by  CERL  to  perform  required 
maintenance.  These  people  have  an  excellent  record  of  keeping  the  copiers  pro- 
ducing high  quality  copies  with  minimum  down  time. 

G.  Burr 
J . Knoke 
M.  Williams 


